123 Main Street, New York, NY 10001

Submit Your BOM

Production Test & Calibration (PN/Jitter, EEPROM, Field Trim Hooks)

Production Test & Calibration (PN/Jitter, EEPROM, Field Trim Hooks)

← Back to:Reference Oscillators & Timing

This page turns phase-noise/jitter testing and calibration into a reproducible loop from lab → production → field: fixed measurement profiles, correlation/uncertainty guardbands, and traceable EEPROM policies prevent “hero numbers” and stop station-to-station or field drift from becoming yield and stability surprises.

Scope, boundaries, and deliverables (Production-facing)

Production timing quality is not a single “best” jitter number—it is the ability to measure, decide, calibrate, store, and verify clock performance repeatably across instruments, sites, operators, temperature, and time.

In-scope production reality
  • PN/jitter measurement chain: fixture + instrument profiles + windows/masks + repeatability controls.
  • Production station actions: what each station measures, how long it takes, what it logs, and how pass/bin decisions are made.
  • Calibration + safe write policy: what can be trimmed, what must be locked, and how parameters are written atomically with rollback.
  • Field hooks: telemetry + remote verification + bounded trims that cannot destabilize the clock tree.
  • Traceability + consistency: golden unit, correlation, guardbands, and root-cause signals baked into records.
Out-of-scope link only (no deep dive)
  • Phase-noise theory, integration math, and jitter-window definitions: Key Specs → Phase Noise & Jitter (this page only standardizes windows/profiles for production use).
  • PCB routing/layout practices (impedance, returns, via strategies): PCB Layout & Routing (this page focuses on fixtures/terminations as measurement variables).
  • Mechanical placement/airflow design for OCXO/MEMS: Thermal & Mechanical (this page only defines warm-up/soak measurement gates).
What this page delivers reusable production assets
A) Test plan artifacts
  • Instrument profiles (characterization / production / field diagnostics)
  • Limits + guardbands tied to conditions (temp, VDD, load, window)
  • Correlation plan (golden unit, traveling standard, offsets)
B) Production station outputs
  • Station SOP: inputs → actions → logs → decisions → rework handling
  • Binning rules (hard-fail vs soft-bin) designed for yield + risk control
  • Trace record schema (SN/lot/fw/profile/fixture/temp/VDD/window/results)
C) Calibration + EEPROM + field hooks
  • EEPROM parameter map (version, CRC, dual-bank, rollback)
  • Write policy (permissions, rate limits, wear limits, brownout safety)
  • Field telemetry + safe trims + remote verification sequence
System view: Lab → ATE → Field closed loop
Lab → ATE → Field closed loop Three-stage closed loop showing profiles and limits moving from lab to production, EEPROM parameters written to units, and field telemetry feeding improvements. Lab ATE / Production Field profiles • golden limits • bins • log telemetry • trims profile EEPROM logs + drift stats → improve limits

Production quality improves when lab characterization produces standardized profiles, production writes versioned parameters, and field telemetry feeds correlation + guardband updates.

Test architecture: what exactly you measure and where it lives

A production test program fails when objects, metrics, record fields, and limits are not standardized. This section defines a single “data model” so every station reports the same truth.

DUT layers where problems hide
  • Source (XO / TCXO / OCXO / MEMS): sets baseline stability and near-carrier noise floor.
  • Cleaner / Attenuator: sets jitter transfer and residual; strongly depends on profile/loop settings.
  • Fanout / Distribution: sets skew, load sensitivity, and channel-to-channel repeatability.
  • Endpoint (ADC/SerDes/PHY/FPGA): final compliance point; failures often come from conditions, not averages.
Measurement taxonomy production-friendly levels
Level-0 · Fast gate
Frequency accuracy, lock status, gross spur presence, temperature and supply context.
Level-1 · Production KPI
RMS jitter with a fixed window, spur mask/magnitude list, and a consistent measurement profile ID.
Level-2 · Characterization anchor
Phase-noise curve across offsets, residual/transfer characterization, and correlation constants used to set guardbands.
Minimum measurement record (schema) must be loggable

Every pass/fail must be reconstructable months later. A record without conditions is not a record.

Identity
sn, lot, station, site, operator
Firmware & configuration
fw_rev, profile_id, output_standard, load_termination, fixture_id
Conditions
temp_c, vdd_v, warmup_state, soak_state
Results & uncertainty
freq_ppm, rj_rms, jitter_window, spur_list, lock_status, uncertainty
Pass criteria rule limits must be conditional

Limits are valid only when the conditions are logged. A “jitter limit” without window/profile/load is undefined in production.

Limit template (use everywhere)
Metric → Condition → Limit → Decision
rj_rms @ (temp_c, vdd_v, load_termination, profile_id, jitter_window) ≤ limit_value → pass / soft_bin / hard_fail
Clock DUT + measurement points map
Clock DUT + Measurement Points Block diagram showing clock chain and what to measure at each node: PN, RMS jitter, spurs, frequency accuracy, and lock status. Source Cleaner Fanout Endpoint PN Freq RJ Spur Skew Load Lock Mask Primary production measurement point Correlation/characterization anchor Proxy metric (fast gate)

Each metric is tied to a node. A result becomes production-usable only when its measurement point and conditions are fixed and logged.

PN/jitter measurement strategy (repeatability first, not hero numbers)

A production-ready strategy optimizes for repeatability and decision quality. “Best” numbers that cannot be reproduced across stations, instruments, and conditions are not production assets.

PN vs RJ decision mapping
Screening (yield gate)
  • Primary: RJ (fixed window) + spur mask + lock status
  • Output: pass / soft-bin / hard-fail with logged conditions
Calibration (write trims)
  • Primary: phase error / TIE proxy + targeted RJ checks
  • Output: trim code + confidence flags + rollback point
Regression (trend + drift)
  • Primary: PN anchors (key offsets) + RJ in the same window
  • Output: correlation constants and guardband updates
Windowing strategy standardize, then compare

RJ is production-usable only when the integration band is fixed to a product/interface family and stored as a window ID. The goal is not to explain the math—only to lock a comparable measurement contract.

Lock these 4 knobs
  • window_id (e.g., RJ_WIN_A) bound to product/interface
  • profile_id (instrument setup asset, not free-form text)
  • load_termination (fixture-controlled, logged)
  • guardband_rule (how limits account for uncertainty)
Store it as a contract
Use a stable tuple:
(window_id, profile_id, load_termination, temp_c, vdd_v)
Spur handling avoid “averaging hides it”
Mask is an asset

Define spur_mask_id as a versioned rule set (offset ranges + thresholds). Results reference the ID; settings are not re-typed per station.

Log top-N, not only “OK”
  • Record a top-N spur list (offset, magnitude, hit/miss)
  • Store a peak/percentile flag when averaging is used
  • Use soft-bin to route “near mask” units to retest
Production simplification proxies + escalation path

Proxies reduce test time, but they must be paired with an escalation path. A proxy is a gate, not the final definition of compliance.

Common proxies (fast)
TIE, period jitter, phase error, cycle-to-cycle jitter, frequency counter gates.
Escalation path (must exist)
  • Proxy fail → retest with production profile
  • Repeated fail → route to characterization profile (audit)
  • Field alarms → run diagnostic profile + upload telemetry
Pitfalls symptoms → first check
RBW/VBW/averaging “changes the world”
  • Symptom: results shift after “minor” setting changes
  • First check: profile_id and mask/window IDs match
  • Action: lock profiles; log a compact profile fingerprint
10 MHz ref/trigger mismatch drift
  • Symptom: day-to-day or station-to-station offsets appear
  • First check: ref source, lock status, and trigger routing
  • Action: ref-in self-check; record ref status in every run
Measurement profiles ladder (Characterization → Production → Field)
Measurement profiles ladder Three-tier ladder showing standardized measurement profiles with fixed window, averaging, mask, and time budget, and arrows indicating correlation and feedback. Characterization profile Production profile Field diagnostic profile window averaging mask time budget window averaging mask time budget window quick check mask telemetry correlate guardband verify

Standardized profiles convert settings into assets: window, mask, averaging, and time budget become comparable across lab, production, and field diagnostics.

Instrumentation & fixtures: how to avoid measuring your setup

In production, the measurement system is part of the product. Repeatability requires fixtures, cables, terminations, and references to be controlled, identified, and self-checked.

Instrument roles responsibility boundaries
PN analyzer / SSA
Characterization anchor and audit sampling. Provides PN curve consistency for correlation and guardbands.
Scope (TIE / phase error)
Production-friendly proxy metrics and fast debugging. Must use fixed bandwidth and capture settings.
Counter
Frequency accuracy and warm-up/soak gating. Useful for quick stability checks before deeper tests.
DMM / temp sensing
Conditions are mandatory: temperature and supply context must be logged for every run.
Fixture consistency treat as a controlled asset
  • fixture_id must cover adapter + cable + termination network.
  • Cables are not “generic”: type and length must be fixed, logged, and audited.
  • Isolation/grounding must be standardized to avoid ground-loop artifacts.
  • ref-in (10 MHz) and trigger routing must be consistent and verified.
Control knobs (log every run)
termination isolation ref-in profile_id
Calibration & self-check before trusting results
Setup checks
  • Open/short/load baseline for fixture + instrument inputs
  • Ref-in validation (lock status + stability)
  • Noise floor check before measuring low jitter
Routine checks
  • Loopback test with a known path (quick health gate)
  • Traveling standard unit to detect station offsets
  • Cable/adapter swap audit when yield shifts
Fixture health pass criteria ensure setup is not dominant
  • Noise floor margin: floor must stay comfortably below the product limits (guardbanded).
  • Loopback jitter: loopback result must be a small fraction of the production limit; otherwise the setup dominates.
  • Ref-in stability: ref lock must remain stable and be recorded per run.
Minimum fields to log for health
fixture_id, profile_id, ref_status, floor_check, loopback_check
Fixture stack-up (DUT → adapter → cable → instrument)
Fixture stack-up Stack-up showing DUT board, adapter, cable, and instrument with labeled control knobs and a fixture health check box. DUT board Adapter Cable Instr. TP mode termination isolation type len profile ref-in Health checks floor loopback ref lock log

The fixture is a measurable asset: each run must record fixture_id, profile_id, and ref status so station-to-station drift can be separated from true DUT variation.

Correlation & uncertainty: golden unit, gage R&R, and limits

Production limits must account for correlation and measurement uncertainty. Without a defined offset/sigma model, “lab-good” results will not translate into stable yields across stations and time.

Standards golden + traveling
Golden unit (reference anchor)
  • Defines the reference baseline under controlled profiles and fixtures.
  • Requires lifecycle controls (health checks, drift tracking, retirement rules).
Log fields
golden_id, golden_rev, golden_health
Traveling standard (site alignment)
  • Runs across instruments/sites to quantify station offsets.
  • Used for new station bring-up and yield-drift investigations.
Log fields
ts_id, route_id, site_id, instrument_id, fixture_id
Correlation plan offsets + sigma

Build a repeatable correlation model by measuring the same DUT across instruments, sites, and days. The deliverable is a table of offset and sigma per station configuration.

Minimum coverage
  • Repeatability: same station, repeated runs (short-term σ).
  • Reproducibility: cross-site cross-instrument (station σ + offsets).
  • Time drift: cross-day checks (cal-cycle sensitivity).
Store as a table asset

Index by the same contract used in measurement records (profile/window/fixture). Update on schedule and on anomalies.

key = (instrument_id, site_id, fixture_id, profile_id, window_id)
value = (offset, sigma, last_update, n_samples, valid_flag)
Gage R&R (minimum) repeatability + reproducibility
Smallest useful design
  • 3 DUTs (near-limit / typical / strong)
  • 2 operators (or 2 sessions if single operator)
  • 3 repeats per condition
Outputs to consume
  • σ_repeat (within-station)
  • σ_reprod (between operators/sites)
  • σ_time (drift / recalibration sensitivity)
Pass criteria guardband rule

Production limits must leave margin for uncertainty. Use a consistent rule so limits remain stable when stations or instruments change.

Sigma-based rule
limit_prod = limit_lab − k · sigma_total

Choose k by misclassification risk (false fail vs false pass). Keep k consistent per product family.

P99-based rule
guardband = P99(error)
limit_prod = limit_lab − guardband

Use historical station error distributions to protect yield stability against rare-but-real shifts.

Correlation matrix (Instrument × Site)
Correlation matrix A 3×3 matrix with columns Instrument A/B/C and rows Site 1/2/3, each cell showing offset and sigma, plus a side card summarizing guardband rules. Instrument A B C Site 1 2 3 Δoffset σ Δoffset σ Δoffset σ Δoffset σ Δoffset σ Δoffset σ Δoffset σ Δoffset σ Δoffset σ Offset & Sigma correct offset sigma model guardband limits = lab − margin

Each cell represents a station configuration (instrument + site). The production-ready outcome is a versioned table of offset and sigma used to compute guardbands and stabilize limits.

Environmental control for production validity (temperature, soak, warm-up)

Environmental steps are defined only from the viewpoint of measurement validity. Temperature and time are not “nice to have” metadata; they determine whether results are comparable and actionable.

Warm-up / soak stability-threshold based

Define “enough warm-up” by a stability threshold, not by minutes. Measurements outside the stability gate must be marked invalid or restricted to coarse gates (e.g., lock/frequency checks).

Gate definition (template)
  • Use a stable metric slope: |Δmetric| over Δt below a threshold.
  • Log the gate status and the metric used to decide stability.
  • Only allow RJ/PN tests when stable_flag=true.
Required log fields
temp_c, temp_sensor_id, warmup_state, stable_flag, stable_metric
Temperature points room / hot / cold
Room (baseline)

Primary production coverage for stable throughput. Provides the main distribution for guardbanding and station control.

Hot / Cold (validity checks)
  • Use for audits, station qualification, and change validation.
  • Ensure warm-up gates and drift models cover temperature stress.
  • Record stable_flag explicitly; temperature alone is not sufficient.
Pitfall warm-up curve sampling bias
  • Symptom: audit samples appear unstable; retest “recovers” without changes.
  • First check: was the stability gate enforced (stable_flag=true)?
  • Action: restrict measurement to the gated window; mark out-of-gate results invalid.
Warm-up & measurement gate (only measure here)
Warm-up and measurement gate Timeline with four phases: power-on, warm-up, stabilize, and measurement window. The measurement window is highlighted with an ONLY MEASURE HERE label. power-on warm-up stabilize measure ONLY MEASURE HERE stable gate Log per run temp_c stable_flag warmup_state

Measurements must be taken inside a defined stability gate. Out-of-gate results should be treated as invalid or limited to coarse checks, and all runs must log temperature and stability status for comparability.

Calibration primitives: what you can trim and what you must not

Treat calibration as a controlled set of approved knobs with explicit side effects. Unbounded tuning often degrades lock margin, spur masks, or EMI compliance.

Approved knobs bounded + logged
DAC trim (frequency)
  • Use: coarse/fine frequency alignment.
  • Side effects: step updates can cause phase transients.
  • Guardrails: small-step iteration inside stability gate.
Varactor bias (VCXO)
  • Use: tracking/holdover bias alignment.
  • Side effects: sensitivity changes can amplify coupled noise.
  • Guardrails: voltage window limits; bounded slew.
Digital correction word (MEMS)
  • Use: frequency alignment with deterministic steps.
  • Side effects: frequent updates can create apparent jitter.
  • Guardrails: write-verify-freeze transactions.
PLL trims (whitelist only)
  • Use: select a pre-qualified profile_id.
  • Side effects: profile changes can shift spurs/EMI.
  • Guardrails: field selects profiles; no free-form loop edits.
Prohibited knobs factory-only / field read-only
Stability-critical loop parameters

Any free-form changes to loop filter coefficients, gain, or continuous bandwidth controls must remain factory-only. Field interfaces should expose these as read-only or as pre-qualified profile selections.

EMI-sensitive modulation controls

Spread-spectrum depth/rate and modulation modes should be gated behind whitelists. Uncontrolled changes risk compliance failures and interoperability breaks.

Policy: access + audit
  • Factory-only fields: signed/locked; updates require controlled tools.
  • Field access: read-only telemetry or profile selection only.
  • All writes: versioned records with rollback support.
Order & pass criteria coarse → fine + minimal regression
Recommended order (template)
  • Select profile_id first (whitelist), then align frequency (coarse → fine).
  • Apply adjustments only inside the stability gate (stable_flag=true).
  • After frequency convergence, verify RJ/spur masks under the fixed measurement window.
Minimal regression set
freq RJ spur mask lock margin

If any item fails, revert to the last-known-good parameter set (banked storage), then re-run the minimum regression.

Trim knobs & side effects (benefit vs risk)
Trim knobs and side effects Left column shows knob cards; each connects to benefit and risk tags. Right side shows access policy and regression set chips. Trim knobs Side effects benefit risk DAC trim freq align phase transient Varactor bias tracking noise coupling MEMS word fine step update jitter PLL profile noise optimize spur / EMI Delay step phase align mis-match Access policy factory-only field-read whitelist Minimal regression freq RJ spur lock

Every knob must be bounded and logged. Field tuning should be limited to profile selections and approved trim codes, with mandatory regression checks after any write.

EEPROM/OTP parameter map: versioning, limits, and write policy

Parameter storage is the production contract between ATE, firmware, and field tools. The map must be versioned, bounded, and power-fail safe, with explicit rollback points.

Partitions write permissions
Factory-only

Calibration coefficients and manufacturing IDs. Optional lock/signature. Field tools should not modify these entries.

Field-writable (whitelist)

Approved trims and profile selections only. Must use write-verify-commit transactions with rollback support.

Runtime-learned

Aging and health counters. Writes must respect endurance budgets and use wear-safe update patterns.

Schema & integrity version + CRC
Header (minimum)
schema_version CRC sequence valid_flag

Optional integrity layers (e.g., signature) can be reserved for factory-only partitions.

Compatibility (policy)
  • Older firmware: ignore unknown fields; use defaults.
  • Newer firmware: map legacy fields; backfill missing values.
  • Reject banks when CRC/version checks fail.
Write policy atomic + rollback
Atomic transaction (banked)
  • Write the inactive bank.
  • Verify CRC and header.
  • Set valid_flag and switch active pointer.
Endurance & power-fail safety
  • Budget write counts per field/partition.
  • Use sequence counters to pick newest valid bank.
  • Keep last-known-good bank for rollback.
Parameter examples card list (no tables)
cal_rev
Scope: factory-only · Rule: increments on successful calibration commit
freq_trim_code
Scope: field-writable (whitelist) · Rule: write-verify-commit; bounded step count
temp_coeff
Scope: factory-only · Rule: updated only under controlled temperature points
aging_est
Scope: runtime-learned · Rule: rate-limited updates; endurance budgeted
last_cal_temp
Scope: factory-only · Rule: written at calibration commit (stable gate required)
lock_profile_id
Scope: field-writable (whitelist) · Rule: selectable preset only; regression required
EEPROM layout with banks (A/B) + header (CRC/version) + valid flag
EEPROM dual-bank layout Two banks (A and B) with header and payload partitions, plus a transaction flow: write inactive bank, CRC check, set valid and switch active. EEPROM / NVM Bank A header ver/CRC payload valid seq Bank B header ver/CRC payload valid seq active_bank → newest valid (seq) Write transaction write inactive CRC check set valid switch active

Dual-bank storage enables atomic updates and rollback. Banks carry a header (schema_version + CRC), a payload, a valid flag, and a sequence counter to select the newest valid entry after resets or power failures.

Field trim & telemetry hooks: safe knobs, logs, and remote verification

Field recovery must be bounded: only safe knobs are allowed, every change is rate-limited, verifiable, and reversible. Telemetry provides the context required to avoid false drift calls.

Safe knobs (whitelist) bounded + rate-limited + rollback
profile_id (preset)
range: whitelist step: preset rate: limited

Field control should select only pre-qualified profiles; free-form loop edits are prohibited. Every switch requires a minimal regression check.

freq_trim_code (small-step)
range: bounded step: LSB cooldown: required rollback: enabled

The field may apply small-step trims only inside a stability gate (stable_flag=true), with rate limits and a one-click rollback to the last-known-good bank.

Field transaction (must)
prepare apply verify commit log

The pipeline prevents partial updates. If verification fails, reject the change and revert to the prior bank before re-testing.

Telemetry (minimum) context + env + health + proxies
Must-report fields
temp stable_flag VDD lock_status drift_est RJ_proxy alarm_latch

Every measurement and decision must bind to its conditions: temperature/stability, supply context, active profile, and the proxy window.

Pitfall: false drift calls
  • Supply noise changes the proxy jitter while frequency offset appears stable.
  • Temperature is not settled (stable_flag=false) during measurements.
  • Reference presence or lock transitions invalidate short snapshots.
Remote verification (self-test) minimal + deterministic
Self-test sequence
  1. Pre-check: stable_flag=true, lock_status=LOCKED, power/temperature within allowed window.
  2. Measure: read freq_offset + RJ_proxy + alarm_latch under a fixed window/profile.
  3. Decide: pass/fail using gate thresholds bound to conditions; on fail, rollback then re-test.
Pass/Fail (template)
freq ≤ TH (cond) RJ_proxy ≤ TH (win) alarm cleared

Thresholds must include measurement context (window/profile) and guardbands derived from uncertainty budgets.

Field closed-loop: telemetry → policy → trim → verify → log
Field closed-loop control Device sends telemetry to host or cloud, policy engine decides, applies trim, verifies with self-test, logs results, and supports rollback. Device clock sensors Telemetry temp VDD RJ Host/Cloud policy engine Policy allow deny Trim apply knob Verify self-test Log append-only Guardrails whitelist rate rollback audit

The loop is valid only when measurements include environmental context and stability flags. Policies should reject unsafe requests and enable rollback on failed verification.

Production flow: station plan, gates, and traceability (ATE/ICT/FCT/Burn-in)

A production-ready flow defines what each station measures, what it writes, and what it logs. Gates must separate hard failures from soft bins, while traceability ensures every number can be reproduced.

Gate design hard fail vs soft bin
Hard fail (invalid or unsafe)
  • No lock / missing reference / incorrect output standard.
  • Record is missing required context fields (profile/window/temp/stable flag).
  • Bank integrity or schema checks fail (CRC/version).
Soft bin (recoverable)
  • Proxy jitter near threshold but lock/health is stable.
  • Spur mask is close to limit and requires re-test with a tighter profile.
  • Assign reason_code + retest_policy_id instead of scrapping.
Traceability (minimum) required fields
SN lot fixture_id station_id operator timestamp fw_hash meas_profile bin reason_code

Records missing these fields should be treated as non-comparable and not eligible for correlation or guardband decisions.

Station plan (template) measures / writes / logs
1) Incoming
measures: freq measures: lock writes: none logs: SN/lot
2) Board-level (ICT/FCT)
measures: RJ measures: ref writes: profile logs: fixture
3) System-level
measures: endpoint measures: lock writes: trim logs: window
4) Burn-in
measures: drift measures: alarms writes: none logs: summary
5) Final
measures: min set writes: commit logs: bin

Each station must bind results to its measurement profile and context fields. Soft bins require reason_code + retest_policy_id to prevent silent escapes.

Station pipeline: Incoming → Board → System → Burn-in → Final (measures / writes / logs)
Production station pipeline Five stations chained with arrows. Each station shows measures, writes, and logs. Gate indicates hard fail vs soft bin and traceability. Gates hard fail soft bin traceability required (SN/fixture/fw/bin) Incoming measures writes logs Board measures writes logs System measures writes logs Burn-in measures writes logs Final measures writes logs Per-station outputs measures (profile-bound) writes (bank commit) logs (traceability + bin) reason_code + retest_policy_id required for soft bins

A station is complete only when it produces: (1) profile-bound measurements, (2) controlled writes (if any), and (3) traceable logs with bin codes.

Engineering checklist (DFT hooks & bring-up → production hardening)

This checklist converts “testability” into verifiable hooks: every item must have an observable readback, a reproducible procedure, and a safe rollback behavior. Use it as a DFT acceptance gate before ramp.

A) Test points TP / MUX / Loopback access
TP-REFIN / TP-REFOUT
  • Expose reference-in and reference-out monitor points with a defined termination_id.
  • Provide a selectable “known-good reference” injection path (for correlation and fault isolation).

Pass criteria: ref_present is readable; switching to known-good ref yields a deterministic lock/holdover outcome and a consistent proxy delta under the same meas_profile.

TP-CLEANER-OUT / TP-ENDPOINT
  • Add a measurement point after the cleaner and at the endpoint side (near the consumer).
  • Bind each point to a defined load/termination state to keep station-to-station comparability.

Pass criteria: both points are accessible without disturbing normal operation, and repeated measurements under the same context stay within the site’s repeatability budget.

B) Mode hooks test mode / bypass / known-good profile
Known-good profile
  • Provide a baseline profile_id stored as factory-default for bring-up and regression.
  • Force deterministic meas_profile_id (window/averaging/mask) in production mode.

Pass criteria: profile_id readback matches the active hardware state; switching into the baseline profile achieves stable_flag=true within the allowed time budget.

Bypass hooks
  • Include a controlled bypass for the cleaner (or an alternate route) for correlation diagnosis.
  • Expose a loopback selection point for closed-path sanity checks.

Pass criteria: bypass/loopback transitions produce explicit lock_reason_code changes (not “unknown”) and leave an audit record.

C) Observability reason codes / counters / last action
Required telemetry registers
lock_status lock_reason alarm_cnt last_trim_cause meas_profile_id

Pass criteria: each field is readable under production mode; counters support reset/freeze policy; fault injection maps to distinct reason codes.

D) Protection field write guard / CRC behavior
Write-guard + integrity
  • Factory-only fields are read-only in the field (policy deny + audit).
  • CRC/version failure must force a safe fallback profile and raise an explicit fault.
  • Atomic updates: no half-written state after power interruption.

Pass criteria: unauthorized writes are rejected with a reason code; corrupted banks trigger safe fallback; rollback restores last-known-good settings and re-verifies successfully.

DFT hooks overlay (TP / MUX / Loopback / Bypass)
DFT hooks overlay Clock tree with Ref to Cleaner to Fanout to Endpoint. Overlays show TP, MUX, loopback, and bypass hooks. Legend TP MUX LB BYP Ref ref-in/out Cleaner profile Fanout skew Endpoint check TP MUX BYP TP TP TP LB Acceptance Each hook must be readable, reproducible (same profile/context), and recoverable (rollback).

The overlay intentionally uses short labels; implementation details live in the board design package and the station SOPs.

Applications & IC selection notes (production-focused)

The goal is not “more parts,” but a BOM-of-trust: components that make measurements comparable, writes atomic, and field adjustments safe. Example material numbers below are starting points—verify package/suffix, limits, and availability.

A) Reference input conditioning & switching (known-good injection)

Selection priority: low additive disturbance, deterministic switching behavior, and a clean way to tag the active path (path_id).

Example material numbers
  • ADI ADG918 (RF switch, SPDT) — simple path select for reference injection.
  • Skyworks SKY13370-374LF (RF switch, SPDT) — alternate RF/clock routing option.
  • ADI ADN4604 (high-speed crosspoint) — multi-path routing for differential clock domains.
  • TI LMK00304 (clock buffer) — reference distribution with defined output standard.

Pitfall: switching without an explicit state tag causes non-comparable records. Always log path_id + meas_profile_id.

B) Isolation & bus integrity (avoid measuring the setup)

Selection priority: deterministic behavior under ground shifts, controlled leakage paths, and clear failure modes during cable/fixture aging.

Example material numbers
  • ADI ADuM1250 / ADuM1251 (I²C isolator) — isolate field/programming bus.
  • TI ISO1540 / ISO1541 (I²C isolator) — alternate I²C isolation path.
  • TI ISO7721 (digital isolator) — SPI/control line isolation for station fixtures.
  • NXP PCA9517 (I²C buffer) — long cable/fixture segmentation (log buffer mode).

Pitfall: isolation without a defined reference and logging can hide intermittent contact issues. Require fixture_id and cable_id in every record.

C) Termination & load network (comparability across stations)

Selection priority: tight tolerance + low tempco + stable package parasitics. Treat termination as a configuration item (termination_id), not a “detail.”

Example material numbers
  • Vishay TNPW0603 (thin-film resistor series) — use 0.1% for critical terminations (define value in BOM).
  • Susumu RG1608P (precision chip resistor series) — stable terminations for repeatability.
  • Vishay ACAS 0606 (resistor array series) — matched networks for differential termination symmetry.
  • TI SN65LVDS1 / SN65LVDS2 (LVDS receiver) — for “endpoint check” fixtures where a real receiver load is required.

Pitfall: swapping array packages silently changes parasitics; log the exact termination_id and fixture revision to keep correlation valid.

D) Temperature sensing (stability gate & context binding)

Selection priority: accuracy + response time + placement strategy that supports a reliable stable_flag gate (not just a raw temperature number).

Example material numbers
  • TI TMP117 (high-accuracy digital temp sensor) — stable gating for production measurements.
  • ADI ADT7420 (digital temp sensor) — alternate digital sensing option.
  • Maxim/ADI MAX31865 (RTD-to-digital) — when RTD probes are used in fixtures.

Pitfall: ignoring self-heating or thermal gradients turns a “stable” reading into a false calibration point. Require stable_flag derived from a slope/variance rule, not a fixed time.

E) Low-noise supply & monitoring (prevent false proxy drift)

Selection priority: noise/PSRR in the band that impacts the clock chain, and a clear way to instrument VDD context (TP-VDD + rail_id).

Example material numbers
  • ADI LT3042 / LT3045 (ultra-low-noise LDO) — common choice for sensitive clock rails.
  • ADI ADM7150 (low-noise LDO) — strong candidate for RF/clock supply islands.
  • TI TPS7A4700 / TPS7A4901 (low-noise LDO) — widely used low-noise rails.
  • TI INA219 (current/voltage monitor) — production-friendly rail context logging (if required).

Pitfall: shared digital rails hide supply-induced proxy jitter. Treat clock rails as a separately logged domain (rail_id) with defined measurement points.

F) Non-volatile storage (EEPROM / FRAM / OTP patterns)

Selection priority: endurance, atomic update strategy, and integrity checks (CRC/version). Prefer parts that fit the banked update policy.

Example material numbers
  • Microchip 24LC256 / 24AA256 (I²C EEPROM) — basic EEPROM for factory params.
  • ST M24C64 (I²C EEPROM) — alternate EEPROM line for parameter storage.
  • Cypress/Infineon FM24CL64B (I²C FRAM) — high endurance for frequent field writes/log pointers.
  • Fujitsu MB85RC256V (I²C FRAM) — alternate FRAM option.
  • Microchip ATECC608A (secure element) — optional for authenticated writes / policy signing.

Pitfall: EEPROM wear from aggressive field trim loops. Enforce rate limits and store only deltas; consider FRAM for high-write domains.

G) Field trim interface (I²C/SPI mapping & safeguards)

Selection priority: clean segmentation, addressability, and safe “deny-by-default” behavior with logging.

Example material numbers
  • TI TCA9548A (I²C mux) — isolate segments and control access paths.
  • NXP PCA9306 (I²C level translator) — controlled level shifting for service ports.
  • TI TCA9617A (I²C buffer) — long-cable resilience in service fixtures.
  • ADI ADuM1250 (I²C isolator) — pair with mux/buffer for robust field service.

Pitfall: allowing raw register writes without a transaction wrapper. Require prepare/apply/verify/commit and a rollback control.

BOM-of-trust (what makes measurements comparable, writes atomic, and field trim safe)
BOM-of-trust Central DUT clock chain is surrounded by modules that protect measurement integrity, write integrity, and field safety. DUT clock chain Ref → Cleaner → Fanout Field-safe hooks Ref switching ADG918 / ADN4604 Isolation ADuM1250 / ISO1540 Termination TNPW / RG / ACAS Temp context TMP117 / ADT7420 Low-noise rail LT3042 / TPS7A47 NVM + integrity

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs (production test & calibration)

Each answer uses the same 4-line, production-ready structure: Likely cause / Quick check / Fix / Pass criteria. All checks must be bound to meas_profile_id + context (temp/VDD/termination/fixture/instrument).

Same DUT, different tester shows different RJ — what’s the first correlation check? Correlation · meas_profile_id · instrument_profile_id · golden/traveling standard
Likely cause: meas_profile mismatch (window/RBW/VBW/avg/mask) or instrument timebase/ref-in/trigger path difference.
Quick check: compare meas_profile_id + instrument_profile_id, then run the same traveling_standard_id on both testers to compute offset (Δ) and σ.
Fix: lock profiles (settings checksum), unify ref-in/trigger, and apply site-to-site correction only if Δ and σ are stable across days (store as site_correlation_rev).
Pass criteria: after alignment, |ΔRJ| ≤ max(3·σ_R&R, P99_offset_guardband) under identical context (temp/VDD/termination/fixture).
PN curve looks “better” after changing RBW/VBW — how to detect a settings artifact? Settings artifact · RBW/VBW/avg · profile checksum · re-run with fixed profile
Likely cause: RBW/VBW/averaging/detector changes altered noise floor presentation or smoothing, not the DUT.
Quick check: require a logged settings_checksum (RBW/VBW/span/avg/detector/ref/trigger) and re-run using the standard meas_profile_id; compare integrated results for the same integration band.
Fix: freeze a “production PN profile” (RBW/VBW/avg/time budget) and reject any record without matching checksum; use peak-hold for spur discovery when relevant.
Pass criteria: under the standard profile, integrated PN/RJ stays within correlation_guardband; any “improvement” must persist with identical checksum + context.
Production yield collapses on Mondays — what environmental/logging field is usually missing? Environmental validity · warm-up gate · stable_flag · instrument warm-up
Likely cause: missing stability gate (only time-based warm-up) or missing instrument/fixture context after weekend thermal drift.
Quick check: compare Monday vs midweek distributions of stable_flag, temp, temp_slope, time_since_power_on, and instrument_cal_state.
Fix: enforce a pre-shift self-check: record noise-floor/loopback results + require slope/variance-based stable_flag before any gating measurement.
Pass criteria: “missing context fields” rate = 0; Monday yield matches baseline within process_control_limit when stable_flag is true.
ATE passes but system fails lock margin — what station-to-station mismatch is most common? Station mismatch · termination/load · output standard · SSC/bypass state
Likely cause: load/termination (and output standard) differs between ATE and the real endpoint; SSC/bypass state also often differs.
Quick check: compare termination_id, load_id, output_standard, SSC_state, and bypass_state between stations; validate with the same traveling standard under both loads.
Fix: add an endpoint-like load module (or receiver-based check) to the ATE path, and lock station configs by revision (fixture_rev, termination_id).
Pass criteria: ATE and system-side proxy metrics converge within site_correlation_guardband for the same DUT, same meas_profile, same load_id.
Spur-only failures: why does averaging hide the issue and how to log spur list correctly? Spurs · average vs peak-hold · spur_list · mask_id
Likely cause: averaging (and wide RBW/VBW choices) reduces spur visibility; integrated metrics can look “OK” while a single spur violates a mask.
Quick check: re-run with peak_hold=true (or max detector), run spur-search, and log a structured list: spur_list=[{offset_Hz, amp_dBc, width_Hz}] with mask_id.
Fix: gate with a spur mask (per product) in production; keep averaging for noise-floor stability but never as the sole spur decision metric.
Pass criteria: under fixed profile + mask, all listed spurs satisfy amp_dBc ≤ mask_limit(offset_Hz); spur_list is repeatable across N runs.
EEPROM parameters “drift” over time — how to separate real aging from write corruption? NVM integrity · schema_version · CRC · dual-bank · write_count
Likely cause: data corruption (brownout/half-write/wear) or schema mismatch; true aging is usually slow and monotonic, not random jumps.
Quick check: read schema_version, CRC_ok, bank_valid, write_count, and brownout_count; compare changes against last_cal_timestamp and last_trim_cause.
Fix: enforce transactional writes (prepare/apply/verify/commit), dual-bank with atomic valid-flag, and rollback to last_known_good_bank on CRC failure.
Pass criteria: CRC_ok always true at boot; any failed update results in automatic rollback; parameter deltas match expected aging model bounds (no unexplained jumps).
Field trim fixes frequency but makes links unstable — what knob likely touched loop stability? Field safety · allowlist · loop BW/damping · SSC/bypass
Likely cause: a “factory-only” loop parameter was modified (loop bandwidth/damping/peaking/holdover behavior) rather than a safe frequency trim code.
Quick check: audit last_trim_cause + changed_fields, then correlate with lock_reason and alarm_cnt deltas; verify only allowlisted fields were writable.
Fix: enforce deny-by-default: field-writable only freq_trim_code (plus bounded rate-limit); keep loop parameters factory-only and revert via rollback if violated.
Pass criteria: after revert, lock alarms return to baseline and remain within alarm_rate_limit; frequency stays within spec under the same temperature and load context.
Golden unit slowly diverges from population — how to refresh the traveling standard process? Golden/traveling standard · drift trend · refresh/re-certification
Likely cause: the “golden” device is aging/being stressed by handling, or the population distribution shifted while correlation models stayed stale.
Quick check: trend golden_offset(t) vs population P50/P90 under the same meas_profile; compare against an independent reference station and log golden_rev + re_cert_date.
Fix: rotate 2+ golden units, re-certify on a master setup, and refresh the traveling standard if drift exceeds threshold; update correlation revision with explicit effective dates.
Pass criteria: golden-to-master offset ≤ golden_drift_limit and slope ≤ drift_slope_limit; site correlation remains stable across refresh cycles.
Warm-up time seems enough, yet results scatter — what “stability gate” should be used instead of time? Stability gate · temp_slope/variance · stable_flag · measure-window gating
Likely cause: the DUT (or fixture/instrument) is still thermally settling; fixed time does not guarantee stable conditions.
Quick check: compute stable_flag from both temp_slope and short-run metric variance (repeat the same quick proxy N times); log time_since_power_on.
Fix: gate measurement only when slope and variance are below limits for a dwell period (e.g., temp_slope ≤ 0.02–0.05 °C/s for 60–180 s) and store the rule as stability_gate_id.
Pass criteria: within-run stddev ≤ repeatability_budget under stable_flag=true; between-run drift is explainable by logged temp/VDD context.
Two fixtures give opposite pass/fail — how to check termination/load equivalence quickly? Fixture equivalence · termination_id/load_id · golden unit A/B · loopback sanity check
Likely cause: termination/load network differs (value, tempco, parasitics), or fixture revision/cable aging changed the effective load.
Quick check: verify termination_id/load_id/fixture_rev, then run the same traveling_standard_id and compare Δ with both fixtures; add a loopback/noise-floor self-check per fixture.
Fix: lock fixture BOM and calibration procedure; treat termination modules as controlled items; replace/retire fixtures whose self-check fails or whose Δ shifts beyond the allowed model.
Pass criteria: fixture-to-fixture Δ on the traveling standard ≤ fixture_equivalence_limit; both fixtures pass the same loopback/noise-floor thresholds before use.
CRC fails after brownout — what dual-bank write policy prevents bricking? Dual-bank · atomic commit · valid flag · rollback to last-known-good
Likely cause: power loss during write caused a partial update; single-bank layouts have no safe fallback.
Quick check: read both banks’ header(version, seq, CRC) + valid_flag; confirm boot chooses last_known_good_bank and increments rollback_count.
Fix: write policy: (1) write payload to inactive bank, (2) write CRC/seq, (3) set valid_flag last (atomic commit), (4) never erase the previous valid bank until commit succeeds.
Pass criteria: after induced brownout at any step, system always boots with a CRC_ok bank; no “brick” state; rollback is logged with a reason code.
Remote verification says “OK” but users report timing slips — what telemetry is missing? Telemetry completeness · lock_reason history · temp/VDD context · event counters
Likely cause: the remote test checks a steady-state snapshot but does not capture event history (holdover/relock/spur hits) or missing context (temp/rail noise/load state).
Quick check: verify logs include lock_reason history, alarm_cnt, holdover_events, meas_profile_id, plus context temp, rail_id/VDD, termination_id.
Fix: add event-stamped telemetry and a minimal remote self-test that forces a controlled perturbation (policy-safe), then verifies recovery and logs before/after deltas.
Pass criteria: every user-reported slip has a correlated telemetry trigger (event/counter/context); remote verification can reproduce and classify the failure mode with explicit reason codes.
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.