123 Main Street, New York, NY 10001

Submit Your BOM

Comparator with Built-In Reference for Programmable Threshold

Comparator with Built-In Reference for Programmable Threshold

← Back to:Comparators & Schmitt Triggers

This page shows how comparators with built-in references/DACs turn power-on and protection thresholds into programmable, production-testable “numbers,” not guesswork. It explains how to map codes to trip points, budget worst-case error (Vref + DAC + offset + leakage), and design the front-end/output so thresholds stay stable from bring-up to temperature and mass production.

What this page solves

Built-in reference/DAC comparators turn “a fixed threshold” into a programmable limit: power-on windows, UVLO/OVP points, multi-level alarms, and field-adjustable thresholds—without adding an external precision reference and threshold generator. This page focuses on when to choose this class, what it replaces, and what it cannot replace.

Three solution paths (and what they optimize)
  • External reference + comparator: maximum control over accuracy and filtering, but higher BOM/area and more sources of drift/leakage.
  • Supervisor: simplest “good-enough” fixed (or limited) thresholds with reset/PG timing, but limited flexibility and fewer programmable levels.
  • Built-in reference + DAC comparator: thresholds become firmware/strap-configurable; best for multi-SKU products, field tuning, and compact window/limit functions.
Choose this class when…
  • Thresholds must be programmable (CODE/strap/OTP) across product variants or field updates.
  • More than one alarm level is needed (multi-level battery, staged fault response, multi-point compliance).
  • A real window is required (valid-power band, brown-in/out with hysteresis).
  • BOM/area must drop versus “external Vref + ladder/DAC + comparator,” while keeping thresholds repeatable.
  • Production/bring-up benefits from fast “code sweep → measured trip curve → binning” workflows.
Not a fit (avoid wrong expectations)
  • Ultra-low edge jitter / ns-class timing pick-off: use high-speed/latched comparator families (this page does not cover that path).
  • Absolute threshold accuracy dominated by external physics (very high source impedance, leakage, contamination): the front-end network becomes the limit unless redesigned.
Three ways to implement thresholds: external reference, supervisor, and built-in reference plus DAC comparator Three-column block diagram comparing BOM and programmability for threshold detection architectures. BOM / Programmability trade-off (threshold detection) External Vref + Comparator Supervisor Built-in Vref + DAC Comparator VIN divider / sensor External precision Vref DAC / ladder (optional) Comparator + OUT BOM ↑ Flex ↑ VIN divider Fixed threshold core Reset / PG timing OUT (RESET / PG) BOM ↓ Flex ↓ VIN divider / sensor Vref + DAC / ladder Comparator core OUT (OD / PP) CODE WINDOW
Reading tip: Built-in reference/DAC comparators reduce external parts while keeping thresholds configurable; accuracy then depends on the internal reference/DAC plus the front-end divider network and leakage control.

Definition & taxonomy: what “built-in reference” really means

“Built-in reference” can mean two very different products. The practical difference is whether the device provides a programmable threshold generator (internal DAC/ladder) or only a stable reference that still requires an external threshold network. Use the checks below to avoid selecting the wrong class.

Two “built-in reference” forms
Type A: Precision Vref only
  • A reference is provided (sometimes on a pin), but the threshold is still set by an external divider/network.
  • Datasheets often lack a CODE → VTH table or programmable threshold registers.
  • Best when a stable reference is needed elsewhere and the comparator threshold is fixed or rarely changed.
Type B: Vref + internal DAC / ladder (programmable thresholds)
  • Thresholds are created internally and applied directly to the comparator input path.
  • Datasheets provide tap/code mapping, resolution, INL/DNL, and sometimes window/multi-level modes.
  • Best for multi-SKU limits, field tuning, multi-point alarms, and windowed power qualification.
Quick datasheet checks (to classify the device in minutes)
  • Is there a CODE/tap table? Look for “threshold code,” “ladder taps,” or “DAC output step.”
  • Is INL/DNL specified? If yes, a DAC/ladder likely exists in the threshold path.
  • Are window or multi-level modes described? That usually implies two thresholds or a programmable limit engine.
  • Is Vref exposed as a pin or internal-only? A Vref pin is helpful but does not guarantee programmable thresholds.
Terminology map (each spec “lands” on a different part of the threshold chain)
  • Vref accuracy / TC / long-term drift: sets absolute threshold stability across temperature and life.
  • DAC resolution: sets the smallest programmable step (does not guarantee linearity).
  • INL/DNL: governs monotonicity and code-to-threshold linear behavior (critical for consistent windows and multi-level alarms).
  • Comparator offset / drift: shifts the effective trip point even with a perfect reference and DAC.
  • Hysteresis (VHYS): trades noise immunity against usable accuracy and window tightness.
Terminology alignment for built-in reference and DAC comparator thresholds Block chain Vref to DAC to threshold node to comparator core to output, with short labels showing which specs affect each block. Specs map to the threshold chain (where each error enters) Vref accuracy • TC DAC / Ladder res • INL/DNL VTH node noise • VHYS Comparator offset • drift OUT Type A (Vref only) Threshold set by external network Type B (Vref + DAC) Threshold generated internally (CODE → VTH) Where specs enter Short labels only
Practical takeaway: A “Vref pin” does not automatically mean programmable thresholds. Look for code/tap mapping and INL/DNL to confirm that the threshold path is internally generated.

Internal architecture map (block-level)

Built-in reference/DAC comparators add a threshold engine inside the IC. Knowing the internal blocks makes it clear where threshold error, noise/chatter, and startup settling actually come from.

Typical internal blocks (what each block “owns”)
  • Bandgap / curvature-correct Vref: absolute trip-point baseline (accuracy, TC, settling).
  • Threshold generator: R-string ladder (taps) or DAC (code) mapping to VTH.
  • Comparator core: input offset/drift, VICR behavior near rails, decision gain.
  • Hysteresis / filter / debounce: anti-chatter under slow ramps/noise.
  • Output stage (OD / push-pull): logic domain behavior, edge strength, pull-up dependence.
  • Control (I²C / SPI / strap / OTP): default code, update timing, power-on state.
Two threshold implementations (practical differences)
R-string ladder threshold (taps)
  • Discrete steps; often strong ratio tracking over temperature.
  • Window/multi-level uses fixed tap points; coarse step is the main limit.
  • Look for: tap mapping, tap tolerance, built-in hysteresis behavior.
DAC threshold (code)
  • Fine steps; supports tight windows and many levels.
  • Linearity/monotonicity depends on INL/DNL and DAC noise/settling.
  • Look for: resolution, INL/DNL, code update timing, DAC settling.
Fast debug map (symptom → likely owner)
  • All thresholds shift together → Vref accuracy/TC or external divider ratio error.
  • Non-linear code-to-trip curve → DAC INL/DNL or ladder tap mapping/tolerance.
  • Startup-only toggling → Vref/DAC settling + POR default code + input slow ramp chatter.
  • Edge/noise toggling near threshold → hysteresis/filtering insufficient or supply/ground bounce at comparator core.
Built-in reference and DAC comparator internal block map Block diagram showing VIN divider feeding a comparator IC with Vref, ladder or DAC, VTH node, comparator core, hysteresis/filter, output stage, and control interface. Internal blocks that create the programmable trip point VIN divider VIN node Comparator IC (built-in Vref + threshold engine) Vref accuracy / TC Threshold engine R-string DAC INL / DNL VTH Comparator core offset / drift VHYS / filter OUT (OD / PP) I²C / SPI / strap POR default code OUT
Design reading: Vref and the threshold engine set the programmable trip-point; comparator offset/drift and the external divider/leakage determine how closely the real trip follows the programmed value.

Threshold programming modes & math (single / window / multi-level)

Threshold programming is usually one of two templates: internal DAC/ladder (CODE → VTH) or Vref + external divider (R ratio sets the trip). The same building blocks can implement a single limit, a window, or multiple alarm levels.

Mapping templates (datasheet-friendly, vendor-agnostic)
Template A — Internal DAC generates VTH (CODE → threshold)
Approx. mapping: VTH ≈ VREF × (CODE / 2N)
  • Step size: LSB ≈ VREF / 2N
  • Real-world note: Vref error + DAC INL/DNL + comparator offset shift the effective trip (handled in the error budget section).
Template B — Internal Vref + external divider sets the trip (R ratio)
  • Common form: VTH = VREF × (1 + Rtop/Rbot)
  • Divider solve: VIN = VREF × (Rbot/(Rtop+Rbot))
  • Practical note: input bias/leakage × source/divider resistance becomes threshold error (keep divider and leakage under control).
Programming workflow (target → code/tap → guardband)
  1. Define targets: single VTH, or window [VL, VH], or levels {V1…Vk}.
  2. Pick the mapping template: internal DAC/ladder or external divider.
  3. Compute a first-pass code: CODE ≈ round(VTH_target / VREF × 2N) (or select the nearest ladder tap).
  4. Apply guardband: ensure window width or level spacing exceeds expected error + noise + hysteresis.
  5. Validate quickly: sweep code/taps and measure actual trip points to confirm monotonicity and drift.
Mode organization (single / window / multi-level)
  • Single threshold: UVLO/OVP trip; add VHYS or time qualification to prevent chatter near the limit.
  • Window: independent VL and VH codes/taps; output is “IN_WINDOW” (logic AND of above-VL and below-VH). VWINDOW = VH − VL
  • Multi-level: multiple thresholds create staged alarms (ALARM1/2/3) or a level code (LEVEL[ ]); ensure spacing exceeds error + VHYS.
Threshold programming modes: single threshold, window, and multi-level alarms Three side-by-side mini block diagrams showing how Vref and DAC/ladder generate thresholds for single, window, and multi-level outputs with short formulas. Single / Window / Multi-level threshold programming Single threshold VIN Vref + DAC Comparator VTH OUT VTH ≈ VREF×CODE/2^N Window VIN VL code VH code Dual compare VL / VH AND IN_WINDOW VWINDOW = VH − VL Multi-level VIN Vref + taps/codes V1 V2 V3 Compare engine levels AL1 AL2 CODEi = round(Vi/VREF×2^N)
Integration note: Window and multi-level designs stay stable only when level spacing (or window width) is larger than expected threshold error, noise, and hysteresis.

Accuracy model: worst-case threshold error budget

A programmable threshold is only useful if the worst-case trip point is predictable. The budget below turns datasheet fields into a single number: the guardband that must be reserved around every threshold or window.

Worst-case workflow (repeatable and production-friendly)
  1. Define the target: VTH, window [VL, VH], or level spacing ΔV.
  2. Choose the mapping: internal DAC/ladder (CODE → VTH) or Vref + divider (R ratio).
  3. Convert each spec to an equivalent ΔVTH: Vref, DAC, offset, leakage, noise.
  4. Sum for worst-case: Guardband ≈ |ΔVref| + |ΔVdac| + |ΔVos| + |ΔVleak| + Vjitter_margin.
  5. Program with margin: VTH_programmed = VTH_target ± Guardband (or widen the window/spacing).
Budget structure (source → equivalence → quick check)
1) Vref initial + TC + aging
  • Equivalent: ΔVTH_ref ≈ VTH_target × (ΔVref/Vref).
  • Quick check: if all trip points shift together across codes, suspect Vref (or divider ratio).
2) DAC quantization + INL/DNL (or ladder tap error)
  • Quantization: ΔVTH_q ≈ ±0.5 LSB, LSB ≈ Vref / 2N.
  • Linearity: ΔVTH_INL ≈ INL_LSB × LSB (use datasheet INL in LSB).
  • Quick check: sweep code; non-uniform steps/curvature indicates INL/tap mapping dominance.
3) Comparator input offset + drift (threshold-equivalent)
  • Equivalent: ΔVTH_os ≈ VOS_equiv (as seen at the comparator inputs).
  • Quick check: if offset changes with temperature similarly at all codes, offset/drift is a prime candidate.
4) Bias/leakage × source/divider resistance
  • Equivalent: ΔV ≈ I_bias_or_leak × R_source_equiv (then mapped by the divider topology).
  • Quick check: scale divider resistors 10×; if the trip shifts, leakage/bias is dominating.
5) Noise / ripple → threshold jitter (effective)
  • Equivalent: Vjitter_eq ≈ Vnoise_rms mapped to the threshold node (plus supply/ground bounce).
  • Quick check: if Vpp ripple near threshold rivals VHYS or guardband, toggling is expected.
When external precision reference or calibration becomes mandatory
  • Very tight relative tolerance: when the target requires sub-percent threshold error across temperature and life, and the summed worst-case budget cannot fit.
  • High-impedance front ends: if divider/source resistance must be high (MΩ-class) and contamination/leakage cannot be guaranteed, I×R drift dominates unless guarded or recalibrated.
  • Narrow windows / dense levels: if VWINDOW or ΔV_level cannot exceed 2×Guardband + VHYS + ripple margin, widen spacing or add calibration/external reference.
Conceptual stacked threshold error budget for worst-case guardband A horizontal stacked bar showing relative contributions from Vref, DAC, comparator offset, leakage, and noise to total threshold uncertainty, plus a guardband marker. Threshold uncertainty = sum of contributions (conceptual, relative only) Total threshold uncertainty (ΔVTH_total) Vref DAC Offset Leak Noise Guardband reserved around thresholds / windows Relative only Use datasheet numbers VWINDOW or ΔVlevel must cover Guardband + VHYS
How to use the chart: identify the largest contributors first; reducing one dominant term often improves accuracy more than “optimizing everything a little.”

Hysteresis, noise immunity, and slow-ramp chatter control

The most common field failure mode is repeated toggling near the threshold: slow ramps plus noise and ripple. Stabilizing the decision requires an explicit choice: hysteresis, RC shaping, or time qualification.

Built-in hysteresis vs external hysteresis (control vs accuracy)
Built-in VHYS
  • Simple and repeatable; no extra resistor network.
  • VHYS range is fixed/limited; may conflict with a narrow window.
  • Best for: general anti-chatter, BOM/area sensitive thresholds.
External hysteresis (feedback)
  • VHYS can be sized to the real ripple/noise environment.
  • Adds resistor tolerance/TC and couples source impedance and leakage into the trip point.
  • Best for: noisy rails, long cables, or slow ramps with strict “one clean edge” requirements.
Decision rules (thresholds → actions)
  • If Vpp ripple near the trip ≳ VHYS: increase VHYS or reduce ripple; otherwise multi-toggling is expected.
  • If the input is a slow ramp (ms–s across the trip): add VHYS or time qualification (debounce/one-shot) to guarantee one transition.
  • If response time is safety-critical: avoid large RC at the input; prefer modest VHYS and digital time qualification.
  • If the window is narrow: keep VHYS small and enforce stability with debounce; ensure VWINDOW ≥ 2×Guardband + VHYS + ripple margin.
Common pitfalls (fast checks)
  • VHYS too large: the effective trip shifts and the usable accuracy/window tightness collapses. Action: verify spacing/window is still larger than 2×Guardband + VHYS + ripple margin.
  • RC too large: the input is slowed and the comparator reacts late to real faults. Action: compare the RC time constant to the allowed fault reaction time; move filtering to time qualification when needed.
Slow ramp input with hysteresis thresholds to prevent chatter A slow ramp VIN curve crosses VTH+ and VTH- lines with output transitions marked, showing how hysteresis prevents repeated toggling under noise. Slow ramp + noise → chatter (hysteresis creates a clean window) time VIN VTH+ VTH− VIN (slow ramp) noise trip ↑ release ↓ OUT VHYS = VTH+ − VTH−
Practical rule: set VHYS (or time qualification) so that ripple and noise near the trip cannot re-cross the opposite threshold during the ramp.

Startup & power behavior: brown-in/out, reference settling, nano-power modes

The most common “it worked on the bench” failures happen in the first second after power-up and near brown-out. Threshold engines need time to become valid: POR → Vref settle → code active → comparator valid.

Power-up sequence (when the threshold is actually valid)
  • Before POR release: registers may not be initialized; output state can be undefined. Action: gate alarms with PG/supervisor or ignore interrupts until initialization is complete.
  • After POR, before Vref settles: the effective trip point can drift as Vref ramps. Action: wait for “Vref ready / tSETTLE” or add a blanking time window.
  • Code write vs code active: a new code may require an update trigger and DAC settling time. Action: follow the datasheet update sequence: write → update → wait tDAC_settle.
Brown-in/brown-out behavior (avoid reset loops and false trips)
  • VICR near undervoltage: input common-mode behavior can change close to the rails. Action: keep comparisons away from VICR edges or add margin around brown-out thresholds.
  • Output predictability during VDD collapse: OD outputs depend on external pull-ups and may back-power without protection. Action: verify the “power-off output state” and prevent back-power paths (see output section).
  • Chatter near UV thresholds: slow VDD ramps + ripple cause repeated toggles. Action: use separate brown-in/brown-out thresholds (hysteresis) or time qualification.
Nano-power and duty-cycled compare (sampling window model)
  • Dynamic bias / intermittent sampling means the comparator decision is not continuous. The event is detected only inside a sampling window.
  • Added detection latency: a fault can wait up to one duty-cycle period before being seen. Action: avoid duty-cycled modes for fast protection cutoffs.
  • Pulse miss risk: short pulses can fall between windows. Action: keep duty-cycled modes for wake-up/slow thresholds, not for transient fault capture.
Power-up timing: VDD, Vref settling, code active, and output validity Four-lane timing diagram showing VDD ramp and POR release, Vref settling, code becoming active after update, and output becoming valid only after these conditions. Power-up validity: POR → Vref settle → code active → OUT valid VDD VREF CODE active OUT not valid time POR release settled update valid wait: tSETTLE + tDAC
Rule of thumb: treat OUT as invalid until Vref is settled and the programmed code is active; gate alarms or add blanking time to prevent false trips.

Output types & logic-domain integration (OD vs push-pull + cross-voltage)

Output choice determines whether a threshold can be aggregated, level-shifted, or safely routed into a logic domain. The key integration questions are wired-OR, pull-up sizing, and power-off behavior.

OD vs push-pull (selection map)
  • Open-drain (OD): best for wired-OR alarms and cross-voltage logic domains using an external pull-up. Watch: pull-up sets rise time and low-state power.
  • Push-pull (PP): clean edges and no pull-up; stronger drive for direct logic inputs. Watch: ground bounce/EMI and domain compatibility.
Pull-up sizing for OD (speed vs power)
  • Rise time driver: Rpullup × (Ctrace + Cin + Cload).
  • Low-state power: OD low draws about Vlogic / Rpullup.
  • Workflow: pick the required rise time → estimate capacitance → choose Rpullup → verify interrupt sampling margin.
Fail-safe checks (power-off, high-Z, and back-power paths)
  • Power-off state: confirm whether OUT becomes high-Z or clamps when VDD collapses.
  • Back-power risk: an external pull-up can feed VDD through internal clamps if not designed for fail-safe IO.
  • Action: use series resistance, dedicated level shifting, or keep pull-ups in the same domain as the receiver.
Open-drain vs push-pull wiring: pull-up placement and wired-OR alarms Two side-by-side block diagrams. Left shows open-drain outputs with a pull-up to VLOGIC enabling wired-OR aggregation into an MCU interrupt. Right shows push-pull output directly driving an MCU input without a pull-up. OD vs push-pull integration (cross-voltage + pull-up placement) Open-drain (OD) OUT OD #1 OUT OD #2 Rpullup VLOGIC MCU INT wired-OR alarms (multi-point) Push-pull (PP) OUT PP MCU GPIO no pull-up required same-domain logic
Integration rule: use OD for wired-OR and cross-voltage domains (pull up to the receiver logic rail), and verify power-off behavior to prevent back-powering.

Front-end network: divider design, source impedance, leakage, protection

Threshold accuracy is often limited by the external network rather than by the internal DAC or reference. The front end must be designed so that I×R errors, leakage paths, and protection parts do not dominate the error budget.

Divider sizing (accuracy vs standby power)
Convert leakage/bias into trip-point shift
  • Thevenin resistance: RTH = Rtop || Rbot.
  • Node shift: ΔVnode ≈ Ileak_total × RTH.
  • Input-side impact: map ΔVnode back to the monitored VIN using the divider ratio (same topology used for VTH math).
Practical sizing rules (thresholds → actions)
  • Accuracy rule: keep Ileak_total × RTH well below the allowed guardband (reserve margin for temperature and humidity).
  • Power rule: divider current Idiv ≈ VIN / (Rtop + Rbot) must fit the standby budget.
  • Workflow: set the maximum standby current → get Rsum; set the maximum I×R shift → get RTH; then solve R ratio for the target trip.
Source impedance, series R, and RC shaping (DC shift vs reaction time)
DC shift channel
  • Template: ΔV ≈ Ibias_or_leak × (Rsource + RTH).
  • Action: if the trip moves when Rsum is scaled (e.g., 10×), leakage/bias is dominating.
Dynamic reaction channel
  • Time constant: τ ≈ Rseries × Cnode (Cnode includes input, TVS/ESD, and trace capacitance).
  • Action: if protection is time-critical, keep τ below the allowed reaction time; move noise control to hysteresis or time qualification first.
Leakage from protection parts and PCB contamination (MΩ paths can dominate)
  • Protection leakage: TVS/clamps can inject or sink current that shifts the divider node, especially at high temperature. Action: include worst-case leakage in the error budget.
  • Moisture/flux residue: surface leakage creates an unknown parallel resistance to the sense node. Action: compare trip points before/after cleaning; repeat under humidity or a controlled wetting test.
  • Stabilization actions: guard ring around the sense node, conformal coating, and spacing improvements.
Protection priority rules (do not break threshold accuracy)
  1. Control leakage first: pick clamps/TVS with acceptable leakage across temperature and voltage.
  2. Series R is dual-use: limits clamp current and forms RC with Cnode; size it by fault current and reaction time.
  3. RC must have one goal: if used for noise, prefer hysteresis/time qualification before increasing τ.
Generic comparator front-end: divider, RC, clamps, and TVS around the sense node Block diagram showing VIN through a series resistor into a sense node with divider resistors, filter capacitor, clamp diodes to rails, and TVS protection, feeding the comparator input. Front-end network (sense node is where accuracy is won or lost) VIN Rseries SENSE NODE Comparator IN Rtop Rbot Cfilter Clamps VDD TVS return bias × R leakage RC delay clean / guard
Design focus: treat the sense node as a precision node—budget leakage and I×R shifts first, then add protection without exceeding the allowed reaction time.

Engineering checklist & verification plan (bring-up → temp → production)

The fastest path to a robust threshold system is a repeatable test plan with a small, consistent dataset. The checklist below turns measurements into pass/fail decisions and root-cause mapping.

Bring-up checklist (day-1 measurements)
  • Stimulus: programmable supply and ramp generator (slow ramp + fast step).
  • Log fields: VIN, VDD, code, Vref state (ready), OUT state, timestamp.
  • Extract: VTH+ / VTH− (up/down trips) and any false toggles during the first second.
  • Action: if slow-ramp toggling is seen, fix VHYS/time qualification before increasing RC.
Temperature sweep (slope, spread, and soak stability)
  • Slope: extract ΔVTH/ΔT (mV/°C) for each threshold and for each unit.
  • Spread: record max–min trip variation across units/boards at each temperature.
  • Soak rule: start measuring only after the trip drift rate |ΔVTH|/Δt becomes small relative to the required guardband margin.
  • Direction check: compare heating vs cooling to detect hysteresis-like behavior in the system.
Production tests (minimal set)
  • Code sweep: sweep codes and measure trip points to verify monotonic behavior and step consistency.
  • Window consistency: measure VL and VH; verify window width and centering stay inside guardband rules.
  • VHYS measurement: measure VTH+ and VTH− under the same conditions; confirm hysteresis matches expectations.
  • Pass/Fail template: |VTH_meas − VTH_target| ≤ Guardband, and VWINDOW ≥ 2×Guardband + VHYS + ripple margin.
Failure analysis (reverse map the budget: fast root-cause order)
  1. Vref first: if all codes shift together, suspect reference behavior or divider ratio.
  2. DAC/ladder next: if code sweep shows curvature or irregular steps, suspect INL/tap mapping.
  3. Offset/drift: if temperature tracking is strong and code dependence is weak, suspect input offset/drift.
  4. Bias/leakage last: scale resistor values or clean/coat; large change indicates I×R or contamination leakage dominance.
Verification flow: stimulus to capture to metrics to decisions and root-cause mapping Flowchart showing stimulus generation, data capture, metric extraction, pass/fail decisions, and a feedback loop to root-cause mapping and design fixes. Verification loop (stimulus → capture → metrics → decision → root cause → fixes) Stimulus ramp / sweep / temp Capture VIN/VDD/code/OUT Metrics VTH/VHYS/slope Decision guardband pass/fail Root-cause mapping (reverse the budget) Vref → DAC/ladder → offset → bias/leakage → contamination Design fixes divider / protection / VHYS / blanking / pull-up / layout hygiene
Execution tip: keep the dataset consistent across bring-up, temperature, and production so failures can be mapped back to the same budget terms.

Application recipes (only those enabled by built-in Vref/DAC)

These recipes focus on the unique value of comparators that include an internal precision reference and/or an internal programmable threshold path (DAC or ladder). Each recipe is written as Goal → Implementation → Pitfalls + thresholds/actions, so the design can be copied into bring-up and production without expanding into unrelated power-stage or protection pages.

Recipe 1 — Custom brown-in / brown-out window (adjustable “valid-power” window)

Goal: Define a configurable “power-valid” window (UV + OV) instead of a single fixed reset point, with guardband control for different SKUs, field calibration, or multi-rail systems.

Implementation:
  • Use the internal Vref as the only accuracy anchor; set UV/OV using external dividers (window device or dual comparators).
  • If a programmable threshold path exists (DAC/ladder), store POR codes that define the default window after reset.
  • Use open-drain outputs when multiple faults must be wired-OR into a single PG/FAULT_N line.
Pitfalls + thresholds/actions:
  • Chatter on slow ramps: if OUT toggles more than once during a monotonic ramp, add hysteresis (preferred) before adding large RC.
  • Window margin rule: keep window separation ≥ 2×(worst-case threshold error) + expected ripple + hysteresis band.
  • Bring-up check: sweep supply up/down and log trip points; verify UV and OV match within the planned guardband at temperature corners.
Example parts (shape examples, not a shopping list)
  • TI TPS3700 — dual comparators + internal reference, open-drain outputs (window / dual monitor).
  • TI TLV3011 / TLV3012 — low-power comparator family with on-chip reference (use Vref + divider for adjustable thresholds).
  • ADI LTC1540 — nanopower comparator with built-in reference for minimal-BOM threshold detection.

Recipe 2 — Programmable OVP/UVP thresholds (field-adjustable limits + glitch immunity)

Goal: Provide remotely adjustable OVP/UVP limits (manufacturing trim, regional variants, firmware updates) without swapping resistor BOMs.

Implementation:
  • Use devices with programmable thresholds (internal DAC/ladder + registers). Convert CODE → VTH using the datasheet mapping.
  • Select output topology based on integration: OD for wired-OR fault trees; push-pull for clean MCU interrupts.
  • Define a firmware policy: write new code → wait settling window → enable fault action (avoid “update-glitch trips”).
Pitfalls + thresholds/actions:
  • Code-update transient: if trips occur only during register writes, add blanking during updates and confirm “code effective” timing on scope/logic.
  • Glitch immunity: if switching noise causes false trips, prefer built-in hysteresis/deglitch (when available) over oversized RC that slows real faults.
  • Cross-domain hazards: verify OD pull-up voltage and power-off leakage behavior when pulling up to a different rail.
Example parts
  • ADI LTC2936 — I²C programmable OV/UV thresholds across multiple channels with dedicated outputs.
  • ADI LTC2933 — similar multi-rail programmable supervisor family (configuration/threshold strategy oriented).
  • TI TPS3890x / TPS388C0x (families) — programmable multi-rail supervision lines (use vendor docs for CODE mapping + timing).

Recipe 3 — Multi-level battery monitor (4/8-level alarms without resistor BOM variants)

Goal: Create multiple thresholds (low / critical / shutdown / recovery) or multi-level fuel alerts by changing codes or using multi-channel programmable detectors.

Implementation:
  • Programmable approach: store a threshold table (codes) and apply “upward vs downward” different codes to create effective hysteresis.
  • Multi-channel approach: use a multi-rail programmable supervisor and dedicate channels to different battery thresholds.
  • Route outputs into a small state machine: debounce → latch (optional) → report level.
Pitfalls + thresholds/actions:
  • Level “ping-pong”: if the level flips near boundaries, widen level spacing or add asymmetric (up/down) thresholds.
  • Spacing rule: spacing ≥ 2×(worst-case threshold error) + ripple + intended hysteresis band.
  • Validation: run a slow ramp + injected ripple test to confirm stable state transitions across temperature.
Example parts
  • ADI LTC2936 / LTC2933 — treat different channels as different “battery level” thresholds.
  • TI DAC53001 / DAC63001 (DACx300x family) — smart DACs that include an internal reference and a programmable comparator mode (use codes for adjustable thresholds and report via comparator output).

Recipe 4 — Valid-power qualifier (“stable-first, then enable”)

Goal: Avoid enabling downstream blocks on a noisy or still-settling rail. Release enable only after a programmable threshold is met and remains stable long enough.

Implementation:
  • Use built-in reference/DAC to define VTH_VALID (and optionally a release threshold for hysteresis).
  • Implement qualifier timing as: compare true → timer runs → assert EN/PG. Timer can be MCU-based or device-based when available.
  • Prefer OD outputs into a single FAULT_N tree when multiple validity conditions must be combined.
Pitfalls + thresholds/actions:
  • Settling coverage: qualifier delay must cover reference settling + threshold update + worst-case rail ring-down.
  • Over-filtering: if real faults must be caught quickly, avoid large RC; use hysteresis + deglitch where possible.
  • Production test: apply controlled ripple; verify EN does not release until ripple stays within the defined band for the full qualify window.
Example parts
  • ADI LTC2936 — programmable thresholds; use comparator outputs + external/MCU qualify logic for stable-release policies.
  • TI TPS3700 — window monitor with internal reference; use OUTA/OUTB to gate an enable (qualify in firmware or with simple logic).
Built-in reference/DAC comparator recipes overview Four recipe cards showing brown-in/out window, programmable OVP/UVP, multi-level monitor, and valid-power qualifier, each with a minimal block chain using Vref and code thresholds. Recipes enabled by built-in Vref/DAC (minimal block view) Brown-in / out window Programmable OVP / UVP Multi-level monitor Valid-power qualifier VIN Divider Vref Comparator OUT PG VIN Code DAC/Vref Comparator FAULT EN BAT Table Code Comparator Level OUT VDD VTH Compare Timer EN

IC selection logic (fields → risk mapping → vendor questions)

Selection for built-in reference/DAC comparators is primarily a risk-control process. The goal is not to “collect specs,” but to map each spec to a failure mode, then define the exact questions and verification steps that close the risk before layout freeze and production.

Step 1 — Decision flow (in priority order)

  1. Threshold accuracy first: Vref accuracy/TC/drift, threshold mapping (DAC/ladder), comparator offset/drift, hysteresis behavior.
  2. Power & startup next: Iq by mode, startup voltage, reference settling, POR default code/output, low-power “sampled compare” delays.
  3. Robustness then: input leakage over temperature, VICR behavior near rails, abs-max and protection interactions with dividers/filters.
  4. Integration last: OD vs push-pull, allowable pull-up voltage, power-off Hi-Z/leakage, interface (I²C/SPI/straps), built-in filter/delay options.

Step 2 — Fields → risk mapping (what each spec can break)

A) Threshold accuracy
  • Vref: initial accuracy, TC, long-term drift → shifts every threshold derived from it.
  • DAC/ladder: resolution, INL/DNL, mapping formula → causes code-dependent threshold error and non-uniform steps.
  • Comparator offset/drift: becomes an additional threshold error term, especially visible on tight windows.
  • Hysteresis: improves stability but shifts effective trip points; must be counted in guardbands.
B) Robustness
  • Input leakage: I_leak × R_TH creates a silent threshold shift (worst with megaohm dividers, humidity, flux residue).
  • VICR near rails: threshold accuracy can degrade close to VDD/GND or during brown-out conditions.
  • Abs-max + protection: clamps/TVS/series-R can inject bias currents or add RC delay that alters trip timing.
C) Power & modes
  • Startup & settling: an early output can be wrong until Vref settles and the programmed code becomes effective.
  • Nanopower modes: “sampled compare” can introduce response latency and narrow effective compare windows.
  • POR defaults: default code/output state must match system safe-state assumptions.
D) Integration
  • OD vs push-pull: OD supports wired-OR and cross-domain pull-up; push-pull gives cleaner edges but can increase ground-bounce/EMI.
  • Pull-up selection: pull-up value trades speed vs static power; verify logic VIH/VIL margins at worst-case sink current.
  • Power-off behavior: confirm Hi-Z/leakage to avoid back-powering through pull-ups or other rails.

Step 3 — Vendor questions (ask for “calculable” answers)

  • Vref: full-temperature accuracy, TC definition method, long-term drift conditions, and allowed bypass capacitance/stability constraints.
  • Threshold mapping: exact CODE → VTH equation(s), rounding/clip behavior, and whether mapping changes by range or reference selection.
  • DAC linearity: INL/DNL definitions, measurement conditions, and how to translate them into threshold uncertainty over the intended code span.
  • Leakage: worst-case input leakage across temperature and input voltage; include any clamp/ESD structures that can inject current.
  • Startup: POR default code and output state, Vref ready/settle timing, and the timing from register write to “new threshold effective.”
  • Outputs: OD allowable pull-up voltage, sink current vs VOL, power-off Hi-Z/leakage, and behavior when VDD is collapsing (brown-out).
Fast verification hooks (copyable)
  • Code-sweep: step codes (or divider points) and record trip voltage; check monotonicity and step uniformity.
  • Temp slope: measure dVTH/dT and compare against the combined Vref+offset+leakage expectation.
  • Leakage probe: repeat trip test with 10× higher divider resistance; large movement indicates leakage/bias dominance.
  • Power-off test: pull-up to the logic rail with VDD removed; verify no back-power and OUT remains defined/Hi-Z as expected.

Step 4 — Part-number examples by “shape” (for faster shortlisting)

Shape 1: Low-power comparator + on-chip reference (Vref + divider thresholds)
  • TI TLV3011 (OD) / TLV3012 (push-pull) — on-chip reference; use external divider for adjustable thresholds.
  • ADI LTC1540 — nanopower comparator with built-in reference for minimal BOM threshold detection.
  • ADI LTC1440 (family) — ultralow power comparator with built-in reference and programmable hysteresis options (shape example for “stability-first” thresholds).
Shape 2: Window / dual monitoring with internal reference
  • TI TPS3700 — dual comparators + internal reference for UV/OV window or independent monitors (OD outputs).
Shape 3: Multi-channel programmable OV/UV thresholds (register-coded supervision)
  • ADI LTC2936 — programmable thresholds across up to six inputs with dedicated outputs (use as multi-level monitor or multi-rail supervisor).
  • ADI LTC2933 — similar multi-rail programmable supervisor family (shape example for “EEPROM + system-level config”).
Shape 4: Smart DACs that include programmable comparator mode (code-driven thresholds)
  • TI DAC53001 / DAC53002 — internal reference and programmable comparator mode (use comparator output as threshold indicator).
  • TI DAC63001 / DAC63002 — same concept at higher resolution (use CODE table + comparator output for multi-level policies).
Selection decision tree for comparators with built-in reference/DAC A decision flow from threshold accuracy to power and startup, robustness, and integration, ending in vendor questions and verification hooks. Selection flow: accuracy → startup → robustness → integration 1) Threshold accuracy Vref TC • INL/DNL • offset/drift • VHYS 2) Power & startup Iq modes • Vref settle • POR code/out • latency 3) Robustness leakage • VICR near rails • abs-max • clamps 4) Integration OD vs PP • pull-up • Hi-Z power-off • interface Ask vendor → Verify with quick hooks CODE→VTH equation • leakage max(T,V) • POR timing • OD pull-up limits code-sweep • temp slope • 10×R divider check • power-off back-power test

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs: troubleshooting and production-ready checks (built-in Vref/DAC)

Each answer follows a repeatable structure: Symptom → Likely causes → Quick checks → Decision thresholds → Actions. The scope stays within built-in reference / threshold-programming comparators and their front-end + output integration.

Why is the measured trip voltage always higher/lower than the threshold code? What 3 items should be checked first?
Symptom: Trip point shows a consistent offset vs the expected CODE→VTH mapping.
Likely causes (check in this order):
  • Reference shift: Vref initial accuracy/TC/settling moves all thresholds together.
  • Mapping/range mismatch: wrong formula, wrong range, clipping, or rounding behavior.
  • Input network shift: I_bias/I_leak × R_TH and divider tolerance move the sensed node.
Quick checks:
  1. Run a small code sweep (≥5 codes). If the curve is a near-parallel shift, suspect Vref/divider ratio; if it bends, suspect DAC INL/DNL or range mapping.
  2. Repeat the same trip test with a 10× lower divider resistance (same ratio). If the trip moves significantly, suspect leakage/bias dominance.
  3. Read back configuration (range bits + code) and verify no silent clipping/rounding at endpoints.
Decision thresholds:
  • Leakage-dominant indicator: if ΔV_trip scales ~proportionally with R_TH (within ~±20%), then I×R is a primary term.
  • Linearity indicator: if max residual to a best-fit line across codes > (planned guardband)/4, then INL/mapping is too large for the window.
Actions:
  • Lock down the exact datasheet mapping (range + equation) and add a software clamp/rounding model that matches the device.
  • If I×R dominates, reduce divider impedance, add guarding/cleaning/conformal coat, or buffer the node.
  • If a constant shift remains, treat it as an offset term and apply a calibration code (only if stable across temperature and time).
The threshold chatters in the first 100 ms after power-up. How to tell Vref-not-settled vs slow-ramp chatter?
Symptom: OUT toggles multiple times shortly after power is applied, even when the input should be “on one side” of the threshold.
Likely causes:
  • Vref/DAC settling: internal reference ramps/settles; effective threshold moves during the first 10–100 ms.
  • Slow-ramp chatter: VIN crosses a narrow/noisy region without enough hysteresis or debounce.
  • POR default mismatch: default code/output state differs from expected safe state.
Quick checks:
  1. Hold VIN at a fixed DC level (well away from threshold) and power-cycle VDD. If OUT still chatters, suspect Vref/POR timing.
  2. Hold VDD stable, then apply a controlled VIN slow ramp. If chatter appears only near crossing, suspect insufficient hysteresis/RC/debounce.
  3. Compare “write code → OUT behavior” with a scope/logic capture: look for a distinct “code effective” moment.
Decision thresholds:
  • Vref-settling indicator: chatter occurs with VIN fixed and disappears after a repeatable time window.
  • Chatter indicator: chatter appears only when VIN passes through the threshold region; adding hysteresis reduces toggles immediately.
Actions:
  • Add a “blanking/qualify” window after power-up: ignore OUT until Vref/code is guaranteed effective.
  • Increase hysteresis or add a small input RC only as needed to limit toggles during slow ramps.
  • Ensure POR default code/output matches the system safe-state assumptions (hardware straps or firmware early init).
Using megaohm dividers causes large threshold drift. How to quantify bias/leakage error?
Symptom: Trip voltage varies with time, humidity, temperature, or board cleanliness when divider values are in the MΩ range.
Likely causes:
  • Input leakage/bias: total input current (device + clamps + contamination) times R_TH.
  • Surface leakage: flux residue/moisture creates effective MΩ paths across nodes.
  • Protection leakage: TVS/clamp devices contribute temperature-dependent leakage.
Quick checks:
  1. Compute the Thevenin resistance: R_TH = (Rtop || Rbot). Estimate node shift: ΔVnode ≈ I_total × R_TH.
  2. Repeat trip measurement with 10× lower divider impedance (same ratio). Compare ΔV_trip.
  3. Perform a humidity/cleaning A/B test (before/after cleaning; optional conformal coat) and re-measure drift.
Decision thresholds:
  • Acceptability rule: keep I_total × R_TH ≤ 0.25×(available guardband) so leakage cannot consume the margin.
  • Dominance rule: if lowering divider impedance by 10× reduces drift by ~10×, leakage/bias is the controlling term.
Actions:
  • Reduce divider impedance or add a buffer; avoid “MΩ by default” when absolute threshold accuracy matters.
  • Use guarding/cleaning and consider conformal coating for high-impedance nodes.
  • Choose lower-leakage protection devices or move clamps to a node that does not load the threshold sense point.
Threshold shift vs temperature is larger than expected. Suspect Vref TC or comparator offset drift first?
Symptom: Trip voltage moves with temperature more than the planned budget.
Likely causes:
  • Vref TC/drift: scales thresholds derived from Vref (often “proportional” behavior across codes).
  • Comparator offset drift: adds an approximately “constant voltage” term at the input that does not scale with code.
  • Leakage TC: input/protection leakage rises with temperature and shifts high-impedance nodes.
Quick checks:
  1. Measure temperature slope at two widely separated codes (or two divider ratios). Compare scaling behavior.
  2. Repeat with a 10× lower divider impedance to see if temperature slope collapses (leakage-driven signature).
  3. Check whether drift direction is consistent across all thresholds (Vref-like) or varies with operating point (offset/leakage-like).
Decision thresholds:
  • Vref-TC signature: slopes at different codes are proportional (ratio stays ~constant).
  • Offset signature: slopes look similar in volts (not percentage) across different codes.
  • Leakage signature: slope changes strongly with divider impedance or humidity/contamination.
Actions:
  • If Vref dominates, increase guardband, consider calibration, or move to a tighter reference architecture for absolute thresholds.
  • If offset dominates, adjust hysteresis/guardband and validate worst-case drift across temperature corners.
  • If leakage dominates, reduce impedance and improve layout/cleanliness/guarding and protection selection.
DAC resolution looks sufficient, but thresholds still feel “not fine.” What noise/ripple terms usually dominate?
Symptom: Different codes do not produce reliably distinguishable trip points; output toggles due to small disturbances.
Likely causes:
  • Input ripple/noise: supply ripple or sensed-node ripple exceeds the effective threshold step.
  • Insufficient hysteresis: narrow/noisy crossing region causes repeat toggling and masks small code changes.
  • Measurement uncertainty: stimulus resolution + ramp rate + sampling timing blur the observed trip point.
Quick checks:
  1. Measure peak-to-peak ripple at the sensed node near the trip point (probe loading minimized).
  2. Repeat the same code sweep with a slower ramp and with added hysteresis; compare repeatability.
  3. Confirm the effective step size at the input: ΔV_step_input = ΔV_step_node / divider_gain (or per the mapping equation).
Decision thresholds:
  • Ripple-dominant: if V_ripple_pp ≥ 0.5×ΔV_step_input, code granularity will not appear in practice.
  • Stability target: choose VHYS ≥ V_ripple_pp (or ≥ ~2×noise RMS) when chatter is the main failure mode.
Actions:
  • Reduce ripple at the sensed node (filtering, better decoupling, shorter loops) before increasing resolution expectations.
  • Add/adjust hysteresis so the system’s minimum meaningful step is above the disturbance floor.
  • Use a repeatable ramp method and sufficient settling time when characterizing thresholds in validation/production.
Open-drain output becomes slow or causes false triggers after adding a pull-up. How to choose pull-up and filtering?
Symptom: OUT rise time is long, edges are rounded, or downstream logic mis-detects transitions.
Likely causes:
  • RC rise-time: pull-up resistor + total capacitance (pin + trace + filter + input load).
  • Weak sink margin: pull-up too strong increases sink current; VOL rises and violates logic thresholds.
  • Coupling/EMI: slow edges can linger in the logic threshold region; noise causes multiple toggles.
Quick checks:
  1. Estimate rise time: t_r ≈ 2.2×R_pull×C_total. Measure and back-calculate C_total.
  2. Check sink current at low: I_sink ≈ (V_pull − VOL)/R_pull. Confirm it stays within the device’s guaranteed sink capability.
  3. Validate logic recognition: confirm downstream VIH/VIL with the measured edge shape and ground bounce.
Decision thresholds:
  • Timing rule: keep t_r ≤ 0.2×(minimum valid pulse width) to avoid pulse shrink/mis-detect.
  • Margin rule: ensure VOL under worst-case I_sink remains below the downstream VIL(max) with margin.
Actions:
  • Tune R_pull from timing + sink constraints; reduce C_total before forcing very small resistors.
  • If EMI/false triggers persist, add hysteresis or a Schmitt/clean-up stage at the receiving input rather than excessive RC.
  • For harsh environments, consider push-pull output or a dedicated buffer if wired-OR is not required.
Adding external hysteresis makes the threshold “less accurate.” How to meet both noise immunity and accuracy?
Symptom: After adding hysteresis, the measured trip point differs from the original target or appears inconsistent.
Likely causes:
  • Misinterpretation: hysteresis creates two thresholds (VTH+ and VTH−), not one.
  • Feedback loading: hysteresis network interacts with divider/source impedance and shifts the mid-point.
  • Output swing mismatch: feedback magnitude depends on actual output high/low levels (OD pull-up, PP swing).
Quick checks:
  1. Measure both directions: record VTH+ on rising VIN and VTH− on falling VIN.
  2. Verify the hysteresis network with real output levels (include OD pull-up voltage and VOL behavior).
  3. Repeat using a lower source impedance to see whether loading is shifting the thresholds.
Decision thresholds:
  • Noise immunity target: set VHYS ≥ V_ripple_pp (or ≥ ~2×noise RMS) at the threshold node.
  • Accuracy target: keep the hysteresis-induced mid-point shift ≤ 0.5×(allowed threshold error band).
Actions:
  • Define the requirement in terms of two thresholds (assert and deassert), not a single number.
  • Recompute feedback using real output levels; redesign resistor ratios to meet both VHYS and mid-point accuracy.
  • If loading is the limiter, lower divider impedance or buffer the sense node.
Adding TVS/clamps shifts the threshold. How to tell leakage vs clamp conduction?
Symptom: Trip voltage changes after adding protection parts (TVS, clamp diodes, input protect networks).
Likely causes:
  • Leakage current: protection leakage adds to I_total and shifts the divider node via I×R_TH.
  • Clamp conduction/knee: the clamp starts conducting near a knee voltage and distorts the node nonlinearly.
  • Board contamination: added parts and routing increase surface leakage paths.
Quick checks:
  1. Sweep the input and log trip voltage vs input amplitude. Look for a “knee” (nonlinear bend) indicating conduction.
  2. Repeat with 10× lower divider impedance. If shift reduces ~10×, leakage is dominant.
  3. Repeat at temperature corners. Strong temperature dependence is a leakage signature.
Decision thresholds:
  • Leakage signature: trip shift ∝ R_TH and increases strongly with temperature/humidity.
  • Conduction signature: trip behavior shows a repeatable knee/curve change near a clamp-related voltage region.
Actions:
  • If leakage dominates: use lower-leakage TVS/clamps, reduce impedance, and improve cleanliness/guarding.
  • If conduction dominates: move the clamp to a different node, add series resistance, or raise clamp knee relative to the sense range.
  • Validate protection choices with the same production sweep used for threshold characterization.
Window detection is required, but upper and lower thresholds are asymmetric. What are the common root causes?
Symptom: Upper threshold error differs from lower threshold error; window width or center shifts unexpectedly.
Likely causes:
  • Different mapping paths: upper/lower use different ranges, references, or rounding rules.
  • Hysteresis applied unevenly: only one comparator path has deglitch/hysteresis or output feedback differs.
  • Leakage polarity effects: input leakage/bias interacts differently depending on which node (high/low) is being compared.
Quick checks:
  1. Verify both thresholds use the same reference/range configuration (read-back and log all config fields).
  2. Measure rising and falling trip points separately for both upper and lower comparators (capture VTH+/VTH−).
  3. Repeat with lower divider impedance to test leakage/bias sensitivity.
Decision thresholds:
  • Config mismatch indicator: asymmetry disappears when both thresholds are forced into the same range/mapping mode.
  • Leakage indicator: asymmetry changes noticeably when divider impedance is altered.
Actions:
  • Standardize configuration: enforce a single mapping mode and consistent rounding policy for both thresholds.
  • Account for hysteresis explicitly: define and validate VTH+/VTH− for both edges and both thresholds.
  • If leakage contributes, reduce impedance and improve the front-end protection/cleanliness strategy.
I²C writes do not take effect or occasionally revert to default. How to validate POR and latch timing?
Symptom: Code updates appear ignored, intermittently revert, or only work after repeated writes.
Likely causes:
  • POR/brown-out reset: undervoltage events reset code registers to POR defaults.
  • Write-to-effective latency: the threshold updates only after an internal timing event or state transition.
  • Bus integrity: marginal I²C timing, pull-ups, or noise causes missed writes or partial configuration.
Quick checks:
  1. Always read back registers after write; log (timestamp, VDD, code, range bits, status flags) for every update.
  2. Capture VDD and SDA/SCL with a logic analyzer through the failure event; look for brown-out dips and repeated start/stop anomalies.
  3. Test a forced “safe update” sequence: write code → wait fixed settle window → verify OUT change → re-read code.
Decision thresholds:
  • POR signature: code reads back as the documented POR default immediately after a VDD dip or restart.
  • Latch/timing signature: code reads back correctly but OUT changes only after a repeatable delay or event (internal update timing).
Actions:
  • Guarantee supply headroom during configuration; add a qualify window if code updates must be glitch-free.
  • Enforce read-back verification and retry policy; treat any mismatch as a fault condition.
  • If brown-out resets are unavoidable, store intended codes and re-apply after restart in a deterministic state.
How can production test quickly sweep INL / threshold linearity error and bin parts?
Symptom: Need a fast screen for “nonlinear threshold response” without running a full exhaustive code sweep.
Likely causes of bin spread:
  • DAC INL/DNL or ladder nonuniformity across code ranges.
  • Reference variation that shifts the entire curve (separate from INL).
  • Test uncertainty (ramp method, timing, noise) that masquerades as nonlinearity.
Quick checks (fast method):
  1. Select 7–9 codes spaced across the used range (avoid endpoints where clipping may occur).
  2. For each code, ramp the stimulus through the threshold and record the trip voltage (use the same ramp rate and settle policy).
  3. Fit a straight line to (code, Vtrip) and compute residuals: res_i = Vtrip_i − Vfit_i.
Decision thresholds (bin rules):
  • Linearity bin: max(|res_i|) ≤ (planned guardband)/4 for “tight linearity” bin.
  • Uncertainty control: repeat one mid-code 3×; if repeatability (peak-to-peak) > (guardband)/6, improve test noise/timing before tightening bins.
Actions:
  • Use two-stage screening: first a coarse 7–9 point residual test, then a deeper sweep only for borderline units.
  • Log both “curve shift” (intercept) and “curve bend” (residual peak) as separate bin features.
  • If bend is large only in a code segment, avoid that code span in system configuration when possible.
What is the minimum set of test points to separate Vref error, DAC INL, divider error, and input leakage?
Symptom: Need a minimal diagnostic plan that identifies the dominant error source with as few measurements as possible.
Likely causes to separate:
  • Vref error: shifts all thresholds proportionally (global gain/offset in CODE→VTH).
  • DAC INL: causes code-dependent curvature (bend) rather than a simple shift.
  • Divider error: wrong ratio shifts node scaling (can look like gain error).
  • Leakage/bias: I×R_TH term that scales with impedance and environment.
Quick checks (minimum plan):
  1. Measure two codes far apart (e.g., low and high within the used range): get Vtrip(code1) and Vtrip(code2).
  2. Repeat the same two-code test with a 10× lower divider impedance (same ratio): get Vtrip_lowR.
  3. Repeat one code at a temperature corner (or a hot plate spot check) to see temperature signature.
Decision thresholds (diagnosis logic):
  • Leakage dominates: if Vtrip changes noticeably with divider impedance (≈ proportional scaling), suspect I×R_TH.
  • INL dominates: if the “slope” between two codes differs from expected and changes with code span, add a third mid-code to confirm curvature.
  • Vref/divider ratio dominates: if all codes shift together (parallel shift) and do not change with impedance, suspect reference or ratio tolerance.
  • Offset drift dominates: if temperature moves trip points by a similar voltage amount at different codes (not proportional), suspect offset drift.
Actions:
  • If leakage is identified, reduce impedance and harden the node (cleaning/guarding/coating and low-leakage protection).
  • If INL is identified, avoid problematic code ranges or add a per-code correction table only if repeatable and test uncertainty is well below the target.
  • If Vref/ratio is identified, tighten the reference/ratio components or apply a single-point calibration if stability allows.
The trip point differs between rising and falling ramps. Is this “error” or expected hysteresis behavior?
Symptom: Measured trip voltage is different on an upward ramp vs a downward ramp.
Likely causes:
  • Built-in/external hysteresis: two thresholds are intentionally defined (VTH+, VTH−).
  • Deglitch/blanking: internal filtering delays recognition and shifts the observed trip vs ramp direction.
  • Output loading feedback: OD pull-up and feedback networks alter effective thresholds.
Quick checks:
  1. Measure both VTH+ and VTH− explicitly and compute VHYS = VTH+ − VTH−.
  2. Repeat with two ramp rates. If the measured trip changes with ramp rate, filtering/RC is involved.
  3. Verify whether hysteresis is enabled/configured by default (register/strap) and whether it is code-dependent.
Decision thresholds:
  • Expected behavior: if VHYS is stable and matches the intended noise margin, the difference is not an accuracy failure.
  • Unexpected behavior: if VHYS varies significantly with code or load, re-check feedback and output swing conditions.
Actions:
  • Define requirements using two thresholds (assert/deassert), then validate both in bring-up and production.
  • If filtering causes excessive shift, reduce RC or adjust deglitch policy while maintaining chatter immunity.
  • If OD feedback affects thresholds, stabilize pull-up and loading (and account for VOL/VOH in calculations).
The trip voltage depends on ramp rate. What is the fastest way to identify the culprit?
Symptom: A faster stimulus ramp trips at a different voltage than a slow ramp.
Likely causes:
  • Input RC + source impedance: the sensed node lags the stimulus; observed trip moves with ramp rate.
  • Sampled/low-power compare mode: periodic sampling creates an effective time quantization of trip detection.
  • Output deglitch: internal filtering delays output assertion and makes trip appear later on fast ramps.
Quick checks:
  1. Compare node voltage vs stimulus voltage (probe at the comparator input node) to confirm lag.
  2. Repeat the test with RC removed (or reduced) and/or with low-power mode disabled (if configurable).
  3. Measure detection latency: time from threshold crossing at the node to OUT transition.
Decision thresholds:
  • RC-dominant: if node lag explains the observed shift: ΔV ≈ (dVIN/dt)×τ, where τ = R_source×C_in (or added RC).
  • Sampled-compare dominant: trip time quantizes in steps of the sampling period; voltage shift scales with ramp slope.
Actions:
  • Set RC and ramp policies so the worst-case lag stays within the planned guardband.
  • If sampled compare is required for power, include its latency in the protection timing budget.
  • Avoid characterizing thresholds with a ramp method that differs from real system dynamics without compensating for lag/latency.
The trip point changes when probing or changing the measurement setup. Why?
Symptom: Trip voltage shifts between test benches, probes, or measurement instruments.
Likely causes:
  • Probe loading: probe input resistance/capacitance loads a high-impedance sense node and changes effective R_TH or RC.
  • Grounding differences: ground offsets and injected noise shift the apparent crossing point.
  • Stimulus uncertainty: ramp rate, settling, and noise floor differ between instruments.
Quick checks:
  1. Measure with two probe types (higher impedance / lower capacitance). Note whether the trip shifts with probe characteristics.
  2. Probe the node and the stimulus simultaneously; confirm whether the node is being loaded (droop or delayed edge).
  3. Repeat with reduced node impedance (temporary parallel resistor) to see if sensitivity disappears.
Decision thresholds:
  • Loading indicator: if trip shifts significantly with probe capacitance or input resistance, the node impedance is too high for repeatable measurement.
  • Noise indicator: if the trip distribution width approaches the guardband fraction (e.g., > guardband/6), measurement noise dominates.
Actions:
  • Standardize measurement loading and grounding; document the probe model and connection method in the test plan.
  • Reduce sense-node impedance (or buffer) when repeatability is required across benches and production stations.
  • Characterize uncertainty first, then tighten bins/guardbands only after the stimulus and capture chain are stable.
How to choose input RC/protection without breaking threshold accuracy or response time?
Symptom: Adding RC/protection improves robustness but shifts thresholds or slows detection too much.
Likely causes:
  • Leakage injection: added parts increase I_total and create I×R_TH threshold shifts.
  • Excessive time constant: RC delays the node; fast faults are detected late.
  • Clamp interaction: protection conduction or capacitance distorts the node near the threshold region.
Quick checks:
  1. Separate requirements: define max allowed detection delay and max allowed threshold shift (guardband consumption).
  2. Estimate worst-case shift: ΔVnode ≈ I_total×R_TH including protection leakage at temperature corners.
  3. Estimate detection lag for a ramp or transient: ΔV ≈ (dVIN/dt)×τ; validate with a fast step test.
Decision thresholds:
  • Accuracy rule: keep leakage-induced shift ≤ 0.25×(available guardband).
  • Timing rule: keep worst-case detection delay ≤ the system’s allowed fault reaction budget (expressed as a fraction of event time).
Actions:
  • Prioritize hysteresis/deglitch over large RC when the goal is chatter immunity without large delay.
  • Select low-leakage protection and place it to minimize loading of the sense node; lower impedance if needed.
  • Validate with two tests: (1) trip accuracy across temperature; (2) response to worst-case fast fault stimulus.
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.