123 Main Street, New York, NY 10001

Digitally-Programmable Filter ICs (I²C/SPI Configurable)

← Back to:Active Filters & Signal Conditioning

A Digitally-Programmable Filter IC turns bandwidth, notch, and gain into software-controlled profiles, so one hardware platform can adapt to many sensors with repeatable production behavior. The real success criteria are not “fc matches,” but predictable spurs/noise/THD and glitch-free updates that meet system error budgets.

H2-1. Definition & When to Use a Digitally-Programmable Filter IC

What it is (module-level definition)

A digitally-programmable filter IC is a signal-conditioning module whose behavior is defined by I²C/SPI register codes—selecting a preset filter type and parameters (e.g., LP/HP/BP/Notch/All-pass, cutoff/center frequency, gain, order, and mode), plus an update mechanism (latch/sync/mute) that determines whether changes are safe during operation.

The core value is repeatable profiles (configuration-as-data) for platform reuse and production consistency—not teaching a specific analog topology or deriving filter coefficients.

What it is NOT (boundary rules that prevent content overlap)

  • Not a topology derivation page (Sallen-Key / MFB / state-variable / biquad math).
  • Not a full anti-alias / reconstruction order-design tutorial (system-wide fc:fs optimization belongs elsewhere).
  • Not a “free-form” DSP filter designer—most devices expose a preset set of responses and steps.
  • Not a guaranteed best choice when the system is limited by physics-level noise floor, ultra-low THD, ultra-wideband, or hard low-latency constraints.

When to use vs. when to avoid (trigger-based checklist)

Use it when these triggers are true
  • Multi-profile platform: one hardware design must support multiple sensors, bandwidths, or standards via configuration.
  • Configuration-as-data: filter behavior must be versioned, logged, and reproduced across units (factory + field).
  • Controlled updates: the system needs defined switching behavior (latch/sync/soft-mute) rather than ad-hoc rewiring.
  • Production consistency: parameters must be screened/bin’d using repeatable codes (and ideally readback/CRC).
  • Serviceability: remote/field reconfiguration reduces re-spin risk and shortens bring-up.
Avoid it when these red flags dominate
  • Noise-floor limited: the in-band noise target is dominated by sensor/front-end physics; the IC’s own noise/spurs may set the floor.
  • Linearity limited: worst-case THD/SFDR must stay extremely low at large swing/drive; any internal switching/nonlinearity becomes critical.
  • Ultra-wideband: the required fc/BW is near the boundary where layout/parasitics and output drive dominate.
  • Hard low-latency: group delay or update settling must be near-zero (control loops, short time-window acquisition).
Pass criteria template (data-structured placeholders)
  • Register readback: config code match = 100% (or CRC OK) after every write.
  • Profile switching: glitch peak < X mV (or < X%FS) at the measurement node.
  • Settling: within ±Y% amplitude error (and ±° phase error if relevant) in < T ms.
  • Repeatability: fc/gain spread across units and temperature ≤ Z (defined by the system budget).
Problem to module to benefit map for digitally-programmable filter IC Three-column box diagram: multi-sensor problems feed a programmable filter IC module, producing platform and consistency benefits. Problem Module Benefit Multi sensors Multi bandwidths Multi standards Programmable Filter IC Profiles Glitchless update I²C / SPI BOM converge Consistency Remote config
Diagram: problems that drive programmable filter IC usage, the module abstraction, and platform-level benefits.

H2-2. System Placement: Where It Sits in the Signal Chain

Three placement patterns (each owns a different budget)

A) After the sensor

Best for front-end bandwidth shaping and interference reduction before downstream blocks. This placement primarily owns the in-band noise and overload behavior seen by the chain.

B) Right before the ADC

Best for anti-alias shaping and predictable performance because it includes the real ADC input environment. This placement owns settling, switching integrity, and driver compatibility.

C) After the DAC

Best for reconstruction / spectral cleanup and output profile switching. This placement owns output spectrum and load-driven distortion (especially with heavy or capacitive loads).

Interfaces & ownership boundaries (who is responsible for what)

  • PGA owns range: gain steps/ranging protect headroom; the programmable filter owns the shape and profile switching rules.
  • FDA owns differential + common-mode: VOCM, symmetry, and ADC drive; the programmable filter should not be treated as the common-mode “owner.”
  • Clamp/ESD owns survival: surge/ESD strategy and current limiting; the programmable filter should be protected from events it was not designed to absorb.
  • Shared-with-MUX is a system choice: the first failure modes are usually glitch, settling window, source-Z dependency, and crosstalk.
Shared MUX: decision model (deep but bounded)
  • Prefer per-channel when update skew/phase matching matters or sampling windows are short.
  • Shared + MUX can work when the system can switch outside acquisition windows and tolerate a defined settling delay.
  • Worst-case validation must include the real source impedance range across sensors and cables, not just a lab generator.

Pass criteria template (placement-aware, measurement-node explicit)

Pass/fail should be defined at the actual ownership node (sensor output, filter output, ADC input, or load), because the same programmable filter can pass on a bench and fail in-circuit.

  • Switch glitch @ node N: peak < X mV (or < X%FS), measured with the real chain connected.
  • Settling @ node N: within ±Y% (and ±° if phase matters) in < T ms after profile change.
  • Update skew (multi-channel): Δt < Tskew (if synchronous switching is required).
  • Crosstalk after MUX switch: < C dB in the band of interest within the acquisition window.
Three placement patterns for programmable filter IC in a signal chain Three-row chain diagram: sensor-front placement, ADC-front placement with optional PGA/FDA, and DAC-back placement. Includes control bus and clock/reference nodes. 3 placement patterns + ownership nodes MCU (I²C/SPI) Clock / Ref A) After sensor B) Before ADC C) After DAC Sensor Optional buffer Prog Filter IC Profile A/B/C Downstream Sensor PGA FDA Prog Filter IC AA / BW shaping ADC DAC Prog Filter IC Reconstruction Load Shared + MUX: validate glitch + settling + source-Z
Diagram: three placement patterns, plus control-bus and clock/reference ownership nodes.

H2-3. Internal Architectures You’ll Encounter (Without Derivations)

Practical taxonomy (module-level only)

“Digitally-programmable filter IC” describes how behavior is selected (via register codes), not a single circuit. In practice, most parts fall into one of three internal families. Each family has a different engineering price tag (spurs, drift, or latency), so classification comes first—before tuning codes, profiles, or selection logic.

Family A — Switched-Capacitor (SC)
Frequency is clock-defined. Key risk: clock-related spurs, injection, and folding behavior when paired with sampling systems.
Family B — Gm-C / OTA-tunable
Frequency is transconductor-defined. Key risk: drift and amplitude-dependent distortion across tuning codes and temperature.
Family C — Digital IIR / Hybrid
Responses are computed in discrete-time. Key risk: latency/phase, coefficient quantization, and sample-rate constraints.

The 3 engineering truths per family (observable + testable)

SC (clock-defined) — what always matters
  • Clock-related behavior is real: spurs often track fCLK and its harmonics; validate by sweeping clock while keeping the input fixed.
  • Injection/feedthrough sets practical linearity: worst codes can appear only at large swing; validate with amplitude + code sweeps.
  • Folding/image risk exists: out-of-band content can reappear in-band in discrete-time behavior; validate by injecting a controlled out-of-band tone.
Gm-C / OTA (tuning-defined) — what always matters
  • Drift drives fc/Q movement: tuning is sensitive to temperature, bias, and aging; validate with warm-up + temperature points.
  • Linearity is amplitude-dependent: distortion can change strongly with signal swing and tuning code; validate with amplitude sweeps per code.
  • Tuning range ≠ usable range: edge codes may trade stability or headroom; validate extremes and define guard-banded operating codes.
Digital IIR / Hybrid (discrete-time) — what always matters
  • Latency/phase is the price: group delay can dominate control loops and short-window acquisition; validate with step/impulse response.
  • Coefficient/quantization effects show up: ripple or small deviations can be code- and frequency-dependent; validate with magnitude/phase sweeps.
  • Sample-rate constraints dominate: fc ranges and response sets depend on internal rates; validate limit points, not only mid-range examples.

The boundary of “programmable” (selection-safe interpretation)

  • Type selectable does not mean arbitrary shaping—most devices provide preset templates and discrete response sets.
  • Order selectable is usually a small set (e.g., a few fixed options), not any integer.
  • Fine step does not guarantee absolute accuracy; repeatability and drift often dominate the real error budget.
  • Update mechanism is part of the architecture: latch/sync/mute determines whether switching is safe in operation.
Pass criteria template (architecture-aware placeholders)
  • SC spur: max spur at fCLK-related bins < X dBc in the band of interest (measured with the real clock path).
  • Gm-C drift: fc variation over temperature/warm-up ≤ Y% within the operating code range (guard-banded).
  • Digital latency: group delay ≤ Tg (or bounded ripple ≤ ΔTg) for the target acquisition window.
  • Worst-code screening: the worst tuning/profile code must still meet THD/SNR targets with margin.
Inside a digitally-programmable filter IC: modules and architecture families Module diagram showing input buffer, optional gain, filter core split into SC, Gm-C, and DSP/IIR blocks, and output driver. External blocks include registers, EEPROM, and clock tree. Programmable Filter IC (module view) Input buffer Gain (opt) Filter core SC spur Gm-C drift DSP IIR latency Output driver Registers EEPROM Clock tree IN OUT
Diagram: module blocks inside the IC and the three common filter-core families (SC, Gm-C, DSP/IIR).

H2-4. Parameter Model: Type, Order, fc/BW, Q, Gain — and What “Step” Means

Parameter dictionary (mode-aware interpretation)

Type / Mode
LP · HP · BP · Notch · All-pass are template choices. “Selectable type” usually means a bounded preset set.
Frequency terms
LP/HP use fc. BP typically uses f0 + BW (or Q). Notch often uses f_notch plus a preset depth behavior.
Order / template set
Order is commonly a small discrete set. Higher order can change phase/latency and settling behavior; guard-band the usable options.
Gain
Gain codes set headroom and distortion risk. A fine gain step is not a substitute for a full ranging strategy (PGA responsibility).

What “step” really means (and what it does NOT)

Step (resolution)
The minimum programmable increment: Δf (frequency step) and ΔG (gain step) between adjacent codes.
Accuracy (absolute error)
The deviation between programmed target and reality at the measurement node: |actual − set|.
Repeatability (scatter)
The spread for the same code across units/time/temperature: the core driver of production consistency.
Three dominant real-world error sources
  • Code quantization: step size creates an irreducible setpoint granularity.
  • Process/temperature drift: fc/Q/gain shift over warm-up and temperature; guard-band is mandatory.
  • Loading interaction: source impedance and board-level loading distort the intended parameter mapping.

Back-solving from system specs (budget-driven templates)

Parameter requirements should be derived from system budgets. The goal is not to maximize knob count, but to ensure the programmable space can meet amplitude/phase/latency targets with margin under drift and loading.

Reusable templates (placeholders)
  • Amplitude budget → fc requirement: allocate ≤ A% of passband amplitude error to fc mapping; require fc repeatability ≤ F% with guard-band G.
  • Latency budget → order/template constraint: enforce group delay ≤ Tg (or ripple ≤ ΔTg) across operating profiles; restrict to allowed order set.
  • Dynamic range budget → gain strategy: ensure gain codes preserve headroom; require worst-code THD/SNR ≥ target + M margin.
Pass criteria (parameter-space screening)
  • Frequency mapping: for selected modes, fc/f0/BW error ≤ X% at all guard-banded codes over temperature.
  • Gain mapping: gain error ≤ Y dB (or ≤ Y%) and no “bad codes” that violate headroom/THD limits.
  • Template set: each preset type/order must have a validated profile list with versioned configuration IDs.
Parameter cube for programmable filter IC: type/order, frequency, and gain Pseudo-3D cube showing three parameter axes and discrete profile points. Each axis is annotated with step and repeatability tags. Type / Order Frequency Gain step repeatability step repeatability step repeatability Key idea Profiles are discrete presets Accuracy depends on drift + loading
Diagram: parameter space is bounded—type/order, frequency, and gain form a discrete profile set with step and repeatability limits.

H2-5. Clocking & Frequency Setting: Reference, Spur, and Jitter Sensitivity

How fc is created (and why it can backfire)

Digitally-programmable filter ICs typically derive the operating frequency from an external reference, an internal PLL, and/or a divider chain. The same choices that extend frequency range and simplify configuration can also introduce spur paths and EMI sensitivity.

External clock
Fast to validate and easy to sweep. Risk concentrates in edge-coupling, return paths, and clock feedthrough into analog nodes.
Internal PLL / fractional synthesis
Expands tuning range. Risk concentrates in reference leakage, PLL spurs, and supply/ground modulation through the loop.
Divider / clock tree
Defines step granularity and update behavior. Risk concentrates in harmonic content and coupling from digital edges into the output spectrum.

Clock-related spur diagnosis (three measurable paths)

Path 1 — Direct feedthrough
  • Signature: spurs track fCLK / harmonics as clock moves.
  • Quick check: sweep clock frequency; spur location moves with it.
  • Fix direction: tighten clock return path, isolation, edge-rate control.
Path 2 — Supply modulation
  • Signature: sidebands/noise change with VDD ripple content.
  • Quick check: correlate VDD ripple spectrum with output spurs.
  • Fix direction: decoupling, ferrite segmentation, quiet reference routing.
Path 3 — Beating / folding
  • Signature: spur pattern shifts when the sampling/sync relationship changes.
  • Quick check: change sample rate / sync; spur positions “jump” predictably.
  • Fix direction: choose coherent clocking or add guard-band and filtering.

Jitter sensitivity (decision path, no long equations)

  1. Identify sensitivity: higher input frequencies, narrower bands, and higher-Q settings increase sensitivity to phase noise.
  2. Validate correlation: keep signal conditions fixed and swap the reference/clock source; check whether the noise floor and sidebands change with clock quality.
  3. Lock a budget: if correlation exists, define a jitter/phase-noise budget for the clock path and enforce it across profiles and temperature.
Pass criteria templates (placeholders)
  • Clock-spur limit: max fCLK-related spur in-band < X dBc (with real clock routing and enclosure).
  • VDD coupling: output spur change < Y dB when VDD ripple is reduced by ΔVr (same profile, same load).
  • Sync robustness: worst-case beating spur < Z dBc across allowed sample-rate/clock combinations.
  • Jitter ceiling: noise floor or sidebands remain within target when using the specified clock quality (budgeted).
Clock tree to fc mapping with spur and measurement paths Block diagram showing CLK input, optional PLL, divider and clock tree driving the filter core and output. Spur paths include clock feedthrough to output and VDD ripple modulation. Three probe points: CLK pin, VDD ripple, and output spur. Clock → PLL/Divider → fc → Spurs (probe the right nodes) CLK IN PLL (opt) Divider /N Clock tree Filter core fc mapping OUT VDD / Decoupling VDD ripple feedthrough Probe: CLK Probe: VDD Probe: OUT spur
Diagram: clock creation blocks, spur coupling paths, and the three probe points that separate feedthrough from supply modulation.

H2-6. Dynamic Range & Distortion: Headroom, CM Control, THD/SFDR Traps

Headroom is a system constraint, not a checkbox

Usable swing is defined by the intersection of input common-mode range, output swing under load, and the distortion/settling limits at the measurement node. “RRIO” claims must be interpreted under the actual load and actual common-mode, not no-load bench conditions.

  • Input headroom: keep the signal + bias inside ICMR across temperature and tolerance.
  • Output headroom: swing-to-rail depends on load (R/C/line) and internal drive limits.
  • Dynamic headroom: even if DC range passes, large-signal settling and distortion may fail near the rails.

CM control (SE vs differential): define the owner

Single-ended chains
Bias/reference networks set the operating point. Headroom failures often show up as rail proximity distortion or slow recovery.
Differential chains
Define who owns VOCM (often an FDA or the ADC input requirement). Without a clear owner, CM drift becomes a dominant distortion trigger.

THD/SFDR traps: the four triggers that dominate failures

Trigger 1 — CM shift
CM movement pushes internal nodes toward nonlinearity. Validate by stepping VOCM/bias and tracking harmonic change.
Trigger 2 — Load C / drive limit
Capacitive load and real cables distort and ring. Validate by load sweep (R/C) at the output node and watch THD/SFDR and settling.
Trigger 3 — Clock feedthrough
Clock edges inject spur and modulate distortion. Validate by clock sweep and by improving clock isolation/return paths.
Trigger 4 — Gain stage saturation
Internal gain/buffer stages clip or compress first. Validate with amplitude sweep per code and identify the earliest distortion “knee”.

Sweep-based diagnosis (repeatable and fast)

  • Amplitude sweep: fixed frequency, sweep input level → find the distortion knee and the usable swing boundary.
  • Frequency sweep: fixed level, sweep frequency → separate bandwidth/compensation issues from near-rail clipping behavior.
  • Load sweep: fixed conditions, vary R/C/line equivalents → identify drive-limited distortion and ringing sensitivity.
Pass criteria templates (placeholders)
  • Usable swing: maintain THD ≤ X dB and SFDR ≥ Y dBc within the defined swing window (real load, real VOCM).
  • Settling after profile/gain change: settle to ±ε% in < T ms without overshoot beyond Vpk.
  • Load robustness: distortion and ringing stay within limits across the specified load envelope (R, C, and cable model).
  • Clock spur guard: fCLK-related spur remains < S dBc under worst-case routing and operating codes.
Headroom map with distortion triggers around the usable swing window Center swing bar shows near-rail red zones and usable green zone. Four surrounding trigger boxes point to the bar: CM shift, Load C, Clock feedthrough, and Gain saturation. Headroom window + distortion triggers (find the knee fast) near rail usable swing near rail VDD GND CM shift Load C Clock feedthrough Gain saturation
Diagram: usable swing is bounded by rails and dynamic behavior; four triggers commonly dominate THD/SFDR failures in real chains.

H2-7. Noise Behavior: In-Band Noise, 1/f Corner, and Source-Z Interaction

Noise types that matter (and what they “move with”)

Noise in a digitally-programmable filter IC is rarely a single number. It is a mix of source noise, IC contribution, clock-related effects, and downstream measurement limits. The fastest way to isolate the dominant term is to observe what changes when fc, gain code, and clock mode change.

Input-referred noise
Dominates when source impedance is high or gain is large. Often reveals itself as sensitivity to source-Z and biasing.
Output / buffer noise
Changes with load and output swing region. Can look “fine” open-load but worsen with realistic R/C/line models.
Clock-related / folding
Spurs or elevated floor that tracks the clock tree or sync relationship. Often improved by reducing edge coupling and VDD modulation.
ADC / measurement limits
A common false culprit. Separate it by swapping the measurement chain or changing integration bandwidth without changing the DUT.

Source-Z & front-end RC interaction (helpful or harmful)

A practical decision path
  1. Clarify the intent: is RC meant for out-of-band suppression/EMI/limit current, or strictly for in-band noise reduction?
  2. Check the signature: if noise improves mainly when RC reduces out-of-band energy, the improvement is often from reduced folding or reduced clock sensitivity.
  3. Audit the trade: confirm the same RC does not create a phase/settling problem (especially during updates and profile changes).
When RC helps
  • Reduces out-of-band pickup that later folds into the band.
  • Limits fast edge coupling into sensitive input nodes.
  • Improves robustness against EMI and cable movement.
When RC hurts
  • Adds phase shift and group-delay variation that can break timing budgets.
  • Worsens settling after code/profile changes (extra pole interacts with the core).
  • Raises effective source impedance seen by the IC, amplifying some noise terms.

Fast measurement recipes (short/open/real source)

Test 1 — Shorted input
Approximates DUT contribution plus measurement floor. Use a consistent integration bandwidth and repeat across gain codes and fc profiles.
Test 2 — Open input
Exposes susceptibility to leakage, pickup, and clock coupling. If open-input noise explodes, treat shielding, bias paths, and clock return as first suspects.
Test 3 — Real source-Z
Recreate the real sensor/cable/front-RC. Compare against short/open results to attribute how much noise comes from the source path versus the IC itself.
How to read Noise vs fc/code
  • Low-frequency rise: suggests 1/f corner, leakage/bias sensitivity, or pickup.
  • Tracks clock: indicates clock-related spurs or folding behavior.
  • Code-specific spikes: points to implementation differences or switching injection at certain profiles.

Data schema & pass criteria templates (placeholders)

Minimum fields to record
  • Profile: mode, order, fc/BW/Q, gain code, clock mode.
  • Input condition: short / open / real source-Z + front-RC (if used).
  • Measurement: integration BW, FFT settings, load condition (R/C/line).
  • Results: in-band noise RMS, low-freq estimate, clock-related spur level, measurement floor reference.
Pass criteria templates
  • In-band noise: ≤ X Vrms within BW=B Hz (real source-Z and load).
  • 1/f dominance: low-frequency metric ≤ Y (defined at f=fL or within a low-freq window).
  • Clock spur: max clock-related spur in-band < S dBc across allowed clock modes.
  • Repeatability: noise result variation ≤ ΔN across re-program cycles (same conditions).
Noise budget stack versus target SNR threshold A stacked bar shows four noise contributors: source noise, IC noise, clock-related noise, and ADC/meas noise. A horizontal threshold line on the right indicates target SNR. Noise budget stack (identify the dominant slice) Source IC noise Clock ADC/meas Source noise IC noise DUT Clock-related ADC / meas Target SNR
Diagram: treat noise as a stack of contributors; the goal is to reduce the dominant slice until the target threshold is met.

H2-8. Switching & Update Integrity: Glitchless Changes, Settling, Sync Across Channels

Update models: immediate apply vs latch-and-sync

Immediate apply
  • Register write takes effect as soon as it lands internally.
  • Multi-byte writes are sequential → channel update skew is inherent.
  • Transient behavior is harder to bound without external gating.
Shadow + latch (sync)
  • Write profiles into shadow registers, then commit with a latch trigger.
  • Enables deterministic timing and aligned multi-channel switching.
  • Works best when the system defines a safe switching window.

Why switching transients happen (root causes)

Coefficient / template jump
The transfer function changes instantly; a transient is expected unless the IC supports cross-fade or zero-cross logic.
State reset / internal re-init
Some implementations clear internal states on profile change, producing a visible step or slow recovery.
Switch injection
Mixed-signal switching injects charge and couples clock content into the output, creating glitch peaks and short bursts of ringing.
Gain stage headroom events
A gain step pushes internal nodes near rails or into nonlinear regions, increasing both glitch and settling time.

Glitchless strategy ladder (from built-in to system guardrails)

If supported in the IC
  • Cross-fade: transition with controlled overlap to avoid abrupt steps.
  • Zero-cross switching: commit at a near-zero point to reduce peak glitch.
  • Timed latch: commit at a known safe time boundary across channels.
System guardrails
  • Mute/hold window: silence or freeze the path during the commit.
  • ADC gating / S&H hold: avoid sampling during the transient window.
  • Schedule updates: commit only in known idle windows (between frames or bursts).

Settling criteria (make “stable” measurable)

  • Glitch peak: transient pk ≤ Gpk (measured at the specified node and bandwidth).
  • Error band: output enters ±εA (amplitude) and/or ±εφ (phase) and stays within the band.
  • Settle time: time to enter and remain within band ≤ Tsettle.
  • Channel sync: inter-channel commit skew ≤ Δt_sync under real bus timing.
Write, latch, switch, and settle timeline with glitch and error band thresholds Timeline shows I2C/SPI writes, a latch/sync trigger, an output transient with a glitch peak threshold, and a settling window bounded by an error band. Includes a channel sync marker. Write → Latch → Switch → Settle (define thresholds) I2C/SPI write Latch / Sync LD Output transient Output ± error band glitch pk settle window commit (sync) Ch sync
Diagram: separate “write time” from “commit time”; bound the transient with a glitch peak limit and a settle error band within a defined window.

H2-9. Control Plane & Calibration Hooks: Registers, EEPROM, Production Consistency

Register map as a control contract (pages, ownership, invariants)

A programmable filter IC becomes a platform component only when its control plane is treated as a contract: configuration is deterministic, states are observable, and versions are traceable. Organize the register map as pages so firmware, production, and field service share the same mental model.

Config page
Profile selection, mode/order, fc/BW/Q, gain code, clock mode, commit behavior.
Status page
Ready/lock flags, overload/saturation hints, error flags, commit completion.
Diagnostic page
Loopback/bypass control, self-test triggers, stimulus select, debug mux (if supported).
Version page
Silicon revision, profile table revision, calibration revision, control schema revision.
Control plane invariants
  • Observable: every critical config must have a readback path.
  • Deterministic: profile commit must be repeatable under the same conditions.
  • Traceable: configuration must map to a versioned identifier and a stored record.

Reliable writes (readback, CRC, atomic commit, brown-out resilience)

Readback + integrity check
  • Write critical blocks, then read back and compare.
  • Use CRC/check bits if provided; treat mismatch as a recoverable fault.
  • Store a configuration fingerprint in firmware logs for traceability.
Atomic commit (avoid half-config)
  • Prefer shadow registers + a latch/sync commit.
  • If latch is unavailable, define a safe update window and apply external mute/gating.
  • Keep “profile commit” as a single, explicit step with a completion check.
Brown-out resilience
  • Record “write-start” and “commit-success” markers.
  • On boot, detect incomplete updates and force a safe default profile.
  • Retry with a bounded loop and log the failure code.
Default power-up policy
Start from a safe baseline profile and load the final operational profile only after rails and clocks are stable. The baseline should minimize headroom risk and avoid features that amplify transients during early boot.

EEPROM / OTP strategy (wear, drift coefficients, field upgrade)

Write budgeting
Separate factory-only fields from serviceable fields. Limit in-field writes to a small set of parameters with clear ownership and rollback rules.
Drift compensation
Store calibration coefficients with a schema version. Any coefficient set must be paired with the profile table revision and the measurement conditions used to derive it.
Upgrade + rollback
Use versioned records and keep a known-good profile as a fallback. Upgrades should never strand the system in an unknown state after a power interruption.
Traceability fields
  • SiliconRev, FWRev, ProfileTableRev, CalRev
  • ProfileID (mode/order/fc/gain/clock mode)
  • ConfigHash (firmware-side fingerprint)

Calibration hooks (loopback, bypass, BIST) + production script schema

Hooks to include
  • Loopback: output-to-input for self-consistency checks.
  • Bypass: straight-through path to isolate filter-core issues.
  • BIST: built-in status and self-test triggers (if available).
  • Test points: CLK, AVDD ripple, DVDD ripple, OUT spectrum reference nodes.
Production script minimum fields
  • DeviceID, Lot, BoardSN, Timestamp
  • SiliconRev, FWRev, ProfileTableRev, CalRev
  • WriteMode (immediate/latch), ReadbackOK
  • ProfileID + conditions (clock mode, load, bandwidth)
  • Metrics: glitch pk, settle time, in-band noise, max spur
  • Result: pass/fail code + guardband placeholders
Pass criteria templates
  • Write integrity: readback mismatch rate = 0 in N cycles under specified noise/EMI conditions.
  • Loopback consistency: loopback gain/phase error within ±XY across profiles.
  • Self-test: BIST/status flags remain clean across commit and warm restarts.
Control plane and calibration hooks: registers, EEPROM, BIST, and loopback Block diagram showing MCU over I2C/SPI controlling registers and shadow commit into a filter core, with EEPROM/OTP storage, BIST, and a loopback switch from output to input. Registers + EEPROM + self-test loopback MCU FW log I2C / SPI Readback Reg Config Status Shadow Commit Filter core Profiles State + internal nodes REV EEPROM / OTP Cal data BIST Diag IN OUT Loopback
Diagram: treat configuration as a versioned contract; add loopback/bypass/BIST hooks so production and field diagnostics are scriptable and repeatable.

H2-10. Power, EMI, and Layout for Mixed-Signal Programmable Filters

Power partitioning: AVDD/DVDD and return path continuity

Reproducing datasheet typical performance on a board depends more on return path control than on schematic intent. Separate analog and digital domains by function, then enforce continuous reference planes so return currents do not cross sensitive nodes.

AVDD / DVDD boundaries
  • Keep digital edge currents inside the digital zone.
  • Route crossings with a deliberate return strategy (avoid “accidental bridges”).
  • Prevent split-plane gaps under clock and sensitive analog traces.
Single-point intent
  • Define where domains meet instead of letting copper decide.
  • Minimize cross-domain loop area for bus and clock returns.
  • Audit via placement to avoid long return detours.

Decoupling hierarchy (near/mid/far) tied to function

Near (pin-level)
Serves fast transient current. Place close to AVDD/DVDD pins with the smallest possible loop area.
Mid (domain island)
Stabilizes each power island and reduces interaction between DVDD edge currents and AVDD noise-sensitive circuits.
Far (bulk)
Supplies low-frequency energy. Use it to prevent long supply sag and to stabilize upstream regulators.

Digital edge coupling and clock routing (three coupling paths)

Trace coupling
Long parallelism between bus/clock lines and analog IO creates deterministic spur injection. Control by spacing, routing layers, and edge conditioning.
Return-path coupling
If digital return currents cross the analog reference region, both noise floor and clock spurs become board-dependent and hard to reproduce.
Supply ripple injection
DVDD edge currents modulate rails. If AVDD is not isolated by layout and decoupling, ripple becomes spur and elevated in-band noise.
Clock & output check points
  • Clock: continuous reference plane, avoid high dv/dt zones, keep return tight.
  • Output: keep away from bus/clock parallel runs; control load return path explicitly.

Verification points & “datasheet reproduction” checklist

Probe points (minimum)
  • CLK pin (edge integrity and coupling signature)
  • AVDD ripple (band of interest)
  • DVDD ripple (edge-current signature)
  • OUT spectrum (spurs + noise floor, consistent RBW/FFT)
Pass criteria templates
  • AVDD ripple: < X mVpp in the defined band and operating mode.
  • Clock-related spur: max spur < S dBc at OUT under worst-case routing.
  • Write robustness: write failure rate < P ppm under specified edge/noise conditions.
  • Profile update: settle time < T with the real load and full firmware sequence.
Layout zones for mixed-signal programmable filters Board zone diagram split into Digital, Clock, and Analog areas, with decoupling markers, keepout bands, and return path arrows illustrating controlled current loops. Layout zones: Digital / Clock / Analog Digital Clock Analog K K MCU I2C/SPI pull-up CLK shield Filter IC AVDD DVDD IN OUT decap bulk bulk return keep edges away
Diagram: enforce zone boundaries, keep reference planes continuous, and place decoupling by loop-area priority to make “typical” performance reproducible on real boards.

H2-11. Engineering Checklist: Bring-Up, Verification, and Production Tests

This section is a copy-paste SOP: a minimal bring-up path, a verification “minimum set,” and a production-ready reporting schema. It is designed to keep results reproducible across benches, firmware versions, and manufacturing lines.

A) Bring-up checklist (make it controllable before “measuring performance”)

1) Power & reset
  • Confirm AVDD/DVDD levels, ramp order, and reset timing (scope at the pins, not only the regulator output).
  • Record ripple at AVDD and DVDD under “idle” and “bus active” conditions; note any correlation with output spurs.
  • Verify decoupling placement and return paths (a “perfect” datasheet setup often assumes very low supply impedance).
2) Clock sanity
  • Measure CLK amplitude, duty cycle, and edge quality at the IC pin (probe loading can mislead—log probe type).
  • If a PLL/clock tree exists, log lock/ready status and the exact operating mode used during measurements.
  • Baseline spur map with “known-good” clock settings before tuning fc/Q/order, so clock issues do not masquerade as filter behavior.
3) Bus & configuration integrity
  • Read device ID/status first; then write a baseline profile; then read back all key registers (CRC/readback if supported).
  • Define a safe default profile (low-risk gain and bandwidth) and require firmware to boot into it before applying “field profiles.”
  • Stress test bus edges (pull-up value, trace length) and log error flags; occasional bit flips often appear as random spurs or “wrong fc.”

B) Verification “minimum set” (covers the dominant failure modes)

Frequency response (magnitude + phase)
  • Run a sweep (or multi-tone points) with fixed input amplitude and defined source impedance.
  • Log key points: passband gain, corner/center frequency, notch depth (if used), and group-delay/phase at guard frequencies.
  • Record the exact profile ID (type/order/fc/Q/gain) and the commit mode (immediate vs latch/sync).
Noise (in-band)
  • Measure with input shorted (or known source-Z). Fix the measurement bandwidth and document RBW/integration method.
  • Repeat at two fc settings to detect clock-related folding or spur-to-noise uplift.
  • Store both RMS noise and peak-to-peak (for “chatter” risk and threshold decisions).
Distortion & spurs (THD/SFDR)
  • Run an amplitude sweep first (headroom trap), then a frequency sweep (clock coupling / dynamic nonlinearity), then a load sweep (drive sensitivity).
  • Use the same FFT settings each time and log them (window, FFT length, averaging, RBW).
  • Always capture “spur near clock / 2·clock / clock±tone” buckets separately from harmonic buckets.
Switching transient & settling
  • Apply the real firmware write sequence and capture the full window: write → latch/commit → transient → settle.
  • Quantify two numbers: Glitch peak (pk or pk-pk) and Settling time into the defined error band (amplitude/phase).
  • Repeat for at least two profile pairs (worst-case fc jump and worst-case gain jump).
Temperature repeatability (same code, same result?)
  • Do not chase “theoretical tempco” here; validate repeatability: same profile ID across temperature points yields stable metrics.
  • Reload the profile multiple times at each temp to catch state-dependent behavior.
  • Store σ (standard deviation) of key metrics rather than only the mean.

C) Production reporting schema (traceable, searchable, and debuggable)

Keep the dataset minimal but complete enough to reproduce conditions and correlate failures with configuration, temperature, and firmware.

Group Fields (examples) Why it matters
Trace BoardSN, DeviceID, Lot/DateCode, Timestamp Enables lot correlation and regression tracking.
Versions SiliconRev, FWRev, ProfileTableRev, CalRev Prevents mixing results across firmware/profile changes.
Conditions TempPoint, VDD, ClockMode/Fclk, Load, SourceZ, MeasurementBW Makes “bench vs line” deltas explainable.
Config ProfileID (type/order/fc/Q/gain), CommitMode (immediate/latch), WriteReadbackOK Links failures to exact parameter codes.
Metrics MagErr, PhaseErr, NoiseRMS, THD, SpurMax, GlitchPk, SettleTime, RepeatSigma Supports binning and root-cause triage.
Pass criteria template (budget-tied placeholders)
  • Frequency response: |ΔMag| < X dB and |ΔPhase| < Y° at defined guard points.
  • Noise: In-band noise (RMS) < N, measured over the declared bandwidth and source-Z.
  • Distortion/spurs: THD < T dBc; Max spur < S dBc (document FFT/RBW).
  • Switching: Glitch pk < G; Settling time < τ into ±E error band.
  • Repeatability: σ(metric) < R for repeated loads of the same profile across temperature points.

D) Reference part numbers (official links; starting points only)

These part numbers are provided to speed up datasheet lookup and prototyping. Selection must be driven by the checklist above (conditions + guardbands), not by typical plots.

Digitally-programmable / clock-tunable filter IC examples
  • MAX262 — microprocessor-programmable universal switched-capacitor active filter (mode + f0 + Q). (ADI)
  • LTC1068 / LTC1068-25 / LTC1068-50 / LTC1068-200 — clock-tunable, multi-section switched-capacitor filter building blocks (fc set by clock ratio). (ADI)
  • MAX7400 / MAX7403 / MAX7404 / MAX7407 — 8th-order lowpass elliptic switched-capacitor filters (clock-tunable corner). (datasheet)
  • MAX7401 / MAX7405 — lowpass Bessel switched-capacitor filters (clock-tunable, step-friendly response). (datasheet)
  • MAX293 / MAX294 / MAX297 — 8th-order lowpass elliptic switched-capacitor filters (clock sets corner). (ADI)
Control/clock helpers commonly used with programmable filters
  • AD5121 / AD5141 — SPI/I²C-compatible digital potentiometers (useful for digitally tunable analog RC filters or trims). (datasheet)
  • LTC6912-1 / LTC6912-2 — SPI-programmable gain amplifiers (gain-step tuning for state-variable / notch structures). (ADI article)
  • SiT3521 — I²C/SPI-programmable MEMS oscillator (convenient clock source for clock-tunable SC filters). (SiTime)

SVG-11. Test flow (bring-up → verification → production schema)

Programmable Filter IC Test Flow Flowchart showing bring-up steps, verification minimum set, switching tests, temperature repeatability, and a structured production report output. Test Flow (SOP) Keep conditions + profile IDs traceable to make results reproducible. 1) Power / Reset / Bus Readback Baseline 2) Frequency Response Mag Phase 3) Noise / THD / Spurs Noise Spur 4) Switch Test Glitch pk Settle time 5) Temp Repeatability → Report Schema σ Bins Output: trace + conditions + profile ID + metrics → reproducible bins and failure codes.

H2-12. Applications (Multi-Sensor Platforms) — Patterns, Not Deep Dives

The goal is to show repeatable “platform patterns”: one hardware design supports multiple sensors and operating modes by switching filter profiles (type/frequency/Q/gain) in a controlled, verifiable way.

A) Pattern rules (avoid cross-mode surprises)

  • Bind each profile to conditions: source-Z, expected amplitude, load, clock mode, and measurement bandwidth.
  • Bind switching to an integrity plan: latch/sync if supported; otherwise add external mute/gate and define a settle window.
  • Bind claims to a trace: board revision + firmware revision + profile table revision + test settings (FFT/RBW).

B) Four platform patterns (3-line template each)

1) Multi-sensor DAQ (same board, multiple bandwidth templates)
Goal: One hardware path supports multiple sensors by switching profiles (LP/BP/notch + gain steps).
Config strategy: Pre-define ProfileIDs per sensor class; boot into a safe baseline, then commit the target profile.
Verify points: readback OK, glitch pk, settle time, in-band noise (fixed bandwidth).
2) Vibration / condition monitoring (bandwidth + notch presets)
Goal: Switch between wideband capture and narrowband/noise-rejection modes without rebuilding the analog chain.
Config strategy: Use a BP/LP base profile plus a notch profile for persistent interferers; commit with latch/sync if available.
Verify points: notch depth repeatability, spur buckets near clock, load sensitivity (cable/fixture swaps).
3) Audio / measurement (phase / group-delay conscious profiles)
Goal: Preserve transient shape and avoid step overshoot by selecting phase-friendly responses and controlled delay.
Config strategy: Maintain “hi-fi” and “fast-settle” presets; avoid switching during active capture unless mute/gate is defined.
Verify points: group-delay consistency, pop/click (glitch), settle into ±E band after profile commit.
4) Bio-potential / low-frequency (hum notch + drift management)
Goal: Suppress 50/60Hz hum while keeping low-frequency content usable and stable over temperature.
Config strategy: Use a notch profile and a low-bandwidth profile; enforce stable power/clock conditions before precision measurements.
Verify points: hum spur bucket, shorted-input noise, repeated-load σ across temperature points.

C) Example BOM mapping (concrete part numbers by pattern)

Programmable filter core choices
  • MAX262 — universal switched-capacitor active filter with microprocessor interface (mode/f0/Q). Good for “profile table” style platforms.
  • LTC1068 family — clock-tunable multi-section SC filter building blocks (compose LP/BP/notch structures around it).
  • MAX7400/MAX7403/MAX7404/MAX7407 — sharp lowpass elliptic (anti-alias / denoise presets by clock).
  • MAX7401/MAX7405 — Bessel lowpass (step-friendly, fast settling presets by clock).
  • MAX293/MAX294/MAX297 — elliptic lowpass with clock-set corner (common “one-knob fc” approach).
Digital control knobs (when “type/order” is fixed but tuning is needed)
  • AD5121 / AD5141 — SPI/I²C digital potentiometers (RC constant trims, frequency steps, or gain trims).
  • LTC6912-1 / LTC6912-2 — SPI PGA (gain-step tuning that also shifts f0/Q in state-variable / notch patterns).
  • SiT3521 — I²C/SPI programmable oscillator (clean “fc knob” for clock-tunable SC filters).

Practical workflow: define 3–6 presets (profiles), then verify each preset with the same test settings, and lock production bins to those verified conditions.

SVG-12. Application patterns board (same hardware, different profiles)

Application Patterns Board for Digitally-Programmable Filter IC A 2×2 board of application patterns (DAQ, Vibration, Audio, Bio) sharing a common profile table and I2C/SPI control into a programmable filter block. Platform Patterns (2×2) Same analog path; switch profiles safely and verify each preset. Profile table Type • fc • Q • Gain I²C/SPI DAQ Sensor PGA Prog Filter ADC/Host Profiles Vibration Sensor Prog Filter ADC Notch Audio Input Prog Filter Out Phase/Delay Bio Electrode Prog Filter ADC 50/60Hz One profile table → controlled switching across modes (define glitch + settle pass criteria per preset).

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-13. FAQs (Digitally-Programmable Filter IC) + JSON-LD

Short, actionable troubleshooting within this page boundary. Each answer uses the same 4-line data structure: Likely cause / Quick check / Fix / Pass criteria.

Why does the device boot into the wrong profile after a brown-out?
Likely cause: Partial register/EEPROM update or an unsafe default path during supply dip.
Quick check: Log POR/brown-out flag + read back ProfileID and commit/state registers immediately after reboot.
Fix: Boot into a “safe baseline” profile, then apply target profile only after power/clock are stable; use write-verify (readback/CRC) and atomic commit.
Pass criteria: After N brown-out events, ProfileID/readback is identical every time and output response matches the baseline-to-target sequence (no random fc/gain).
I wrote registers successfully, but the response is unchanged—why?
Likely cause: Values were written to a shadow page but never committed (or to the wrong bank/profile page).
Quick check: Read back both “shadow” and “active” registers; check commit/ready flags and version/status pages.
Fix: Use a deterministic sequence: write → readback/CRC → commit/latch → wait-ready; lock profile writes behind a single API.
Pass criteria: For every write, readback matches and the measured fc/gain/mode changes within the declared settle window τ.
Why do I see random spurs only when I²C/SPI traffic is active?
Likely cause: Digital edge/return currents modulate AVDD/ground or couple into the analog path.
Quick check: Compare output FFT with bus idle vs bus toggling; probe AVDD ripple and ground bounce during transactions.
Fix: Add series resistors on SCLK/SDA/SCL, optimize pull-ups, shorten loops/returns, improve local decoupling, and schedule bus activity outside capture windows.
Pass criteria: With bus active, Max spur increase ≤ S dB and in-band noise increase ≤ N (same FFT/RBW and same profile).
Why is there a strong spur at fCLK (or 2·fCLK) at the output?
Likely cause: Clock feedthrough or clock-related supply modulation leaking into the filter core/output stage.
Quick check: Correlate spur amplitude with CLK amplitude/mode and AVDD ripple; move clock frequency slightly and see if the spur tracks exactly.
Fix: Reduce clock edge aggressiveness, improve clock routing/keepout, add proper AVDD decoupling hierarchy, and isolate clock return from analog return.
Pass criteria: Clock spur bucket (fCLK, 2·fCLK, fCLK±tone) stays below S dBc under the declared measurement settings.
Why does the noise floor rise when I change the clock even if fc stays the same?
Likely cause: Clock mode changes spur distribution/folding or increases clock-related noise injection.
Quick check: Measure in-band noise at two clock modes with identical RBW/integration; check if discrete spurs appear and “lift” the floor.
Fix: Choose a clock mode that minimizes spur buckets near the passband; improve clock/AVDD isolation; avoid PLL settings that add close-in noise.
Pass criteria: In-band noise_rms remains within ±N across supported clock modes (same profile, same bandwidth definition).
My fc is correct, but I see beating/low-frequency wobble—what causes it?
Likely cause: Beat notes from clock relationships (clock vs sampling vs interferers) creating a low-frequency envelope.
Quick check: Change clock slightly (small ΔfCLK) and observe if the wobble frequency shifts; check for nearby strong interferers/hum.
Fix: Move clock/sample relationships away from integer ratios; reposition notch/band edges; reduce coupling paths that translate the beat into the passband.
Pass criteria: Envelope wobble amplitude drops below X (or disappears) across the expected clock tolerance range.
VOCM looks stable at DC, but distortion is still bad—why?
Likely cause: Dynamic headroom or common-mode movement under signal/load pushes internal stages into nonlinearity.
Quick check: Run amplitude sweep + load sweep; watch THD/SFDR collapse near rails or with capacitive load changes.
Fix: Reduce swing, adjust gain distribution, ensure proper VOCM source/drive, and avoid heavy capacitive loading (add isolation if needed).
Pass criteria: THD < T dBc and Max spur < S dBc at the specified output swing and load (same FFT settings).
Why does THD get worse mainly at large amplitude but not at small signals?
Likely cause: Headroom limits, gain-stage saturation, or switch nonlinearity becoming dominant at high swing.
Quick check: Perform an amplitude sweep at fixed frequency; note the “knee” where THD rapidly worsens and whether it aligns with rail margin.
Fix: Reduce swing or redistribute gain (upstream/downstream), keep operating CM within safe range, and avoid driving heavy loads directly.
Pass criteria: At the declared max operating amplitude, THD remains < T dBc with margin (no knee within the intended range).
Why does adding input RC reduce noise but worsen response/settling?
Likely cause: Increased source impedance interacts with the input network, causing phase shift and longer settling even if broadband noise is lower.
Quick check: Compare step/settling (or tone-to-tone switching) with and without RC; log settle time into ±E band and any phase error increase.
Fix: Move filtering to a lower-impedance point, reduce R, buffer the source, or constrain RC so the source-Z seen by the IC stays within the intended range.
Pass criteria: With RC installed, settle time < τ and steady-state error stays within ±E (phase and magnitude) for the target profile set.
How do I separate “IC noise” from “source noise” quickly?
Likely cause: Mixed contributions (source, IC, clock-related) are being integrated without a consistent bandwidth and impedance definition.
Quick check: Measure noise with input shorted (or known low-Z) vs with the real source-Z; keep measurement bandwidth identical and log RBW/integration method.
Fix: Define a standard noise procedure per profile (source-Z, bandwidth, averaging); use two-point substitution (low-Z vs real-Z) to isolate source contribution.
Pass criteria: Repeated runs yield σ(noise_rms) < R and the low-Z baseline matches expectations across clock modes (no unexplained uplift).
Profile switching causes a glitch—how do I make changes effectively glitchless?
Likely cause: State/coefficients change instantly, internal nodes re-initialize, or gain steps inject charge/offset.
Quick check: Capture the full timeline (write → commit/latch → transient → settle) and measure glitch pk and settle time into ±E.
Fix: Prefer shadow registers + latch/sync; otherwise add external mute/hold (ADC gating or S/H), and switch only at defined windows (e.g., near zero-crossing if applicable).
Pass criteria: Glitch pk < G and settling < τ into ±E band for the worst-case profile jump (fc and gain).
How do I synchronize profile updates across multiple channels?
Likely cause: Channels commit at different instants, creating transient mismatch (phase/level) even if steady-state profiles match.
Quick check: Toggle two channels with the same write sequence and measure inter-channel skew and mismatch during the transient window.
Fix: Use hardware latch/sync if supported; otherwise stage writes then issue a single “commit” event, or gate downstream sampling until all channels report ready.
Pass criteria: During switching, inter-channel mismatch stays within |ΔMag| < X dB and |ΔPhase| < Y° after τ, and no channel exceeds glitch pk limit G.