123 Main Street, New York, NY 10001

Submit Your BOM

Gm-C / OTA-Tunable Filters for Electronically Tunable f0/Q

Gm-C / OTA-Tunable Filters for Electronically Tunable f0/Q

← Back to:Active Filters & Signal Conditioning

Gm-C / OTA-tunable filters deliver electronically adjustable f0 and Q so one analog front end can track changing bandwidth needs and hold performance across PVT. The real success criteria are monotonic tuning, stable high-Q operation, and measurable noise/distortion budgets backed by calibration and verification hooks.

What is a Gm-C / OTA-Tunable Filter

A Gm-C (OTA-C) tunable filter is a continuous-time filter built from transconductors (OTAs, “gm” elements) and capacitors, where the pole/zero locations are set mainly by gm/C. It is used when a system must electronically tune corner frequency f0 and/or quality factor Q across modes or across PVT drift, often with a calibration loop that writes back tuning codes.

Engineering definition (keep the contract tight)
  • What: OTA(s) convert voltage to current (i ≈ gm·vin), and capacitors integrate that current to shape frequency response.
  • How tuning works: f0 tracks gm/C; Q is set by gm ratios, feedback coefficients, or Q-enhancement loops (when present).
  • Control knobs: gm is adjusted by bias current / DAC code; sometimes Ceff is adjusted by capacitor banks/varactors to extend range or improve monotonicity.
Gm-C tunable filter in the signal chain Block diagram: signal source to tunable Gm-C filter to ADC and DSP; a bias/code control and optional calibration loop adjust f0 and Q. Tunable continuous-time filter block Signal Source Source-Z Gm-C / OTA Filter OTA C OTA Tunable f0 / Q ADC Load-Z DSP / Control Bias / Code DAC / Register Calibration Measure & Retune Key idea: frequency accuracy and mode changes are handled by tuning + (optional) calibration, not passive tolerances.
Placement view: a tunable Gm-C block sits between the source and the ADC/DSP, controlled by bias/code and often stabilized by a calibration loop.

Decision guide (keep scope local to Gm-C)

Use when
  • Bandwidth and center frequency must be programmable (multi-mode, adaptive BW, or channel selection).
  • Frequency response must stay aligned across process/voltage/temperature using retuning or a self-cal loop.
  • Integration/area is important and the system can trade some linearity for tunability and calibratability.
Avoid when
  • Absolute distortion and large-swing headroom dominate (a different implementation may be more predictable).
  • Production cannot support tuning/calibration steps, code storage, or periodic re-trim across temperature.
  • Response must be insensitive to load/probing variations, but buffering cannot be allocated in the signal chain.
Watch out
  • Tuning code ≠ constant linearity: THD/IIP3 and noise can vary strongly with gm setting and signal swing.
  • Q-enhancement can trade precision for stability margin; “almost stable” looks like ripple, slow recovery, or burst oscillations.
  • Bias/reference noise and CMFB dynamics can appear as passband ripple or unexpected settling tails in time-domain tests.

System Placement & Boundary

In a real signal chain, a tunable Gm-C filter is best treated as a contracted interface block: it receives a signal from a defined source impedance, drives a defined load, and must meet a set of measurable response, noise, linearity, and common-mode targets under those conditions. Defining this boundary up front prevents later “scope creep” and keeps tuning and calibration decisions aligned with system-level pass/fail criteria.

Typical placements (each implies a different acceptance test)
  • Anti-alias / pre-ADC shaping: stopband control and overload recovery matter as much as passband ripple.
  • Baseband channel select / anti-blocking: Q, notch depth, and IIP3 constraints drive OTA bias and tuning range.
  • Variable-BW noise bandwidth control: in-band integrated noise and settling time must be co-optimized (BW is a trade knob).
Specification contract for a tunable Gm-C filter Diagram showing the filter as a DUT between source and load impedances with tags for bandwidth, ripple, stopband, noise, distortion, common-mode, and power, plus tuning/control and pass criteria. Specification contract (define before designing) BW Ripple Stopband Noise IIP3 / THD CM Power Tuning / Code Source Source-Z defined Filter DUT Gm-C / OTA Tunable OTA C OTA Load Load-Z defined Pass criteria Response Noise Linearity Acceptance must be defined at specific tuning codes, source/load conditions, and measurement bandwidth.
Boundary view: treat the tunable filter as a DUT with defined source/load impedance and explicit pass/fail metrics at stated tuning codes.

Minimal interface spec (define these before any tuning strategy)

Bandwidth & corner accuracy
Define target f0/BW across required modes and temperature; specify allowable error per mode (not only “typical”). Test condition: stated tuning code(s), stated source-Z and load-Z, measured with a consistent amplitude that avoids compression.
Passband ripple / peaking / Q
State ripple or peaking limits and how Q is interpreted (e.g., peak gain, -3 dB BW, or pole Q in a model). Test condition: sweep response at multiple tuning codes; verify stability margin by observing step response or settling tails.
Stopband attenuation
Specify stopband level at defined offsets from BW/f0; avoid vague “high attenuation” wording. Test condition: measure at defined frequency points (e.g., k×BW away), using consistent instrument floor and averaging settings.
Phase / group delay (only if the application cares)
Make phase requirements explicit: group delay flatness, allowable ripple, or allowable latency over the passband. Test condition: same response sweep as magnitude, but ensure probing and load capacitance are controlled to prevent false phase shifts.
In-band noise (definition must be unambiguous)
Decide whether noise is specified as input-referred or output integrated; define integration bandwidth and source impedance. Test condition: stated measurement BW, stated gain, stated load, and a repeatable method for separating instrument noise from DUT noise.
Linearity / distortion (THD, IMD, IIP3)
Require distortion across tuning codes and signal levels; tunable gm changes linear range, so “one number” is rarely sufficient. Test condition: defined tone levels, two-tone spacing (for IIP3), and a defined load (since load can change distortion and stability).
Common-mode behavior (differential chains)
Specify VOCM target, allowable CM ripple, CM settling, and how CMFB stability is evaluated (time-domain symptoms are common). Test condition: stated supply, stated VOCM, and a defined load capacitance; CM tests must not be altered by probing capacitance.
Power / supply / tuning dynamics
Specify current consumption versus tuning code and the required tuning settle time; define acceptable code-step transient behavior. Test condition: step the tuning code (or bias) and verify that response and output settle within an explicit time window.
Boundary note (to prevent cross-page overlap)

This section defines what must be guaranteed and how it is measured. Implementation details (OTA architecture, tuning loop design, stability margin shaping, and calibration algorithms) belong to later sections of this page. Buffering choices can be referenced as an interface requirement, but detailed buffer/FDA design is handled on the dedicated FDA/driver page.

Core Architectures in Gm-C (From 1st-order to biquad cells)

A continuous-time Gm-C filter is built from a small set of repeatable cells: integrators, summers, and feedback paths. Architecture selection should focus on tuning behavior (how f0/Q move with code), sensitivity (PVT, ro, parasitics, load), and dynamic range (how peaking and headroom impact linearity).

Architecture map (3 families, each with a different “best-for”)

These families implement the same 2nd-order goal in different ways. The difference is not “math” but how tuning and non-idealities translate into f0/Q drift, ripple, and distortion.

Gm-C architecture map Three-column block diagram: SVF cell, biquad cell, and ladder-like structure, each built from integrators and feedback with a best-for tag. Core Gm-C architecture families SVF Cell Biquad Cell Ladder-like Int Int Summer LP BP HP Best for: tunable BP Int Int Mix k 2nd-order Best for: compact cell S1 S2 S3 Feedback Best for: low sens The “best” choice is set by tuning behavior, sensitivity to non-idealities, and required dynamic range.
Three internal families cover most Gm-C implementations: SVF-style multi-output cells, compact biquad cells, and ladder/leapfrog-like structures with improved sensitivity behavior.

From 1st-order building blocks to 2nd-order cells

1st-order: Gm-C integrator
One sentence: an OTA converts voltage to current and a capacitor integrates it, creating a tunable pole where frequency scales with gm/C.
Engineering tradeoffs: (1) finite OTA output resistance behaves like a leak path and moves the effective pole; (2) tuning gm also shifts linear range and noise.
2nd-order: how poles/Q are formed
One sentence: two integrators plus structured feedback create a 2nd-order response where f0 is set mainly by gm/C and Q by gm ratios and feedback coefficients.
Engineering tradeoffs: (1) strong peaking increases overload risk and distortion sensitivity; (2) load and parasitics can translate directly into Q/ripple changes.

Differential implementations and Q control

Single-ended vs fully differential
One sentence: fully differential Gm-C filters are common because controlled common-mode (via CMFB) and even-order distortion suppression improve system robustness.
Engineering tradeoffs: (1) CMFB dynamics can introduce ripple or slow settling if underdamped; (2) common-mode headroom limits can silently reduce usable signal swing.
Q tuning / Q enhancement
One sentence: Q is usually tuned by gm ratios and feedback coefficients; “Q enhancement” may add an effective negative resistance to sharpen poles.
Engineering tradeoffs: (1) Q enhancement narrows stability margin and can create burst oscillation under PVT or large-signal events; (2) Q may become code-sensitive and non-monotonic without calibration.
Practical selection cues (quick, testable)
  • Need multi-output (LP/BP/HP) and simple tuning knobs? SVF-style cells are commonly preferred.
  • Need compact 2nd-order blocks for programmable chains? Biquad cells are a natural fit.
  • Need lower sensitivity and more robust pole placement? Ladder/leapfrog-like structures are often selected, at the cost of complexity.

OTA Fundamentals that Matter for Filters (gm, linear range, output resistance)

In a Gm-C filter, the OTA is not “just an amplifier” — it is a controlled transconductor. Any OTA non-ideality will show up as one (or more) of four measurable outcomes: f0 drift, Q change (ripple/peaking), in-band noise, and distortion (THD/IMD/IIP3).

OTA black-box view (what must be tracked)
OTA black-box model for Gm-C filters Diagram with differential inputs, gm-controlled current source, finite ro, output nodes, headroom rails, and a CMFB feedback loop, indicating impacts on f0/Q, noise, and distortion. OTA black-box elements that set filter behavior VDD VSS Headroom vin+ vin- CM range OTA (gm element) gm · vin ro vout+ vout- Load / C CMFB loop f0 / Q shift Noise THD / IMD
Track gm, finite ro, headroom, and CMFB dynamics. These items directly map into f0/Q drift, in-band noise, and distortion across tuning codes.

gm as the primary tuning knob (and why it is never “only frequency”)

  • Frequency scaling: for many Gm-C cells, f0 tracks gm/C. Any bias or temperature drift that changes gm becomes f0 drift at a fixed code.
  • Noise and linear range move with gm: increasing gm can reduce some noise terms but often changes linear range and the distortion sweet spot.
  • Code-to-code behavior matters: gm tuning should be evaluated for monotonicity, repeatability, and settling (response after a code step).

Ideal vs non-ideal OTA behaviors (each must be tied to a measurable symptom)

Finite output resistance (ro)
Effect: acts like a leak path; shifts poles and reduces effective Q, especially near high-Q settings.
Symptom: peaking/ripple changes with load or probe capacitance; target Q “shrinks” on hardware.
Quick check: repeat the same sweep with two known loads; large response deltas point to ro/parasitic sensitivity.
Mitigation: reduce sensitivity (architecture choice), add buffering where allowed, or re-allocate Q to reduce peaking under worst-case load.
Headroom and output swing limits
Effect: compression and nonlinearity appear earlier than expected; distortion can vary sharply across tuning codes.
Symptom: THD rises and passband peak compresses at certain codes; time-domain recovery shows long tails after overload.
Quick check: sweep input level at a few tuning codes; look for early clipping or sudden THD slope changes.
Mitigation: constrain swing at high-Q codes, re-bias for more headroom, or adjust response targets to reduce peak gain.
Input common-mode limits and CMFB dynamics
Effect: CMFB underdamping shows up as ripple, slow settling, or code-step “ringing” even when DC CM looks correct.
Symptom: passband ripple changes with VOCM or with load capacitance; settling tails persist after tuning code steps.
Quick check: step tuning code and observe output CM and differential settling separately; compare across two VOCM settings.
Mitigation: ensure CM stability margin, reduce CM sensitivity to load C, and avoid operating near CM headroom edges.
gm nonlinearity (large-signal behavior)
Effect: IMD/THD increases as gm departs from linear region; high-Q settings amplify nonlinear artifacts.
Symptom: IIP3/THD varies with tuning code; blockers create unexpected in-band intermodulation.
Quick check: run two-tone tests at a few codes and compare IMD slopes; strong code dependence indicates gm nonlinearity dominance.
Mitigation: apply linearization (degeneration/local feedback/multi-gm segmentation) or reduce required peaking under worst-case blockers.

Linearization toolbox (benefit + cost, no device-level deep dive)

Source degeneration
Benefit: improves linear range and reduces gm curvature. Cost: reduces effective gm, so the same BW may require more bias current.
Local feedback
Benefit: stabilizes effective transconductance and improves predictability. Cost: may reduce tuning range or introduce additional stability constraints.
Multi-gm segmentation
Benefit: improves code-to-code consistency and large-signal behavior. Cost: adds control complexity and may require calibration to maintain monotonicity.
Common-mode stabilization
Benefit: reduces CM-induced ripple and settling tails in differential filters. Cost: may increase power or reduce headroom margin if not budgeted early.
Section boundary note

This section defines OTA behaviors that shape filter outcomes. Control laws for f0/Q tuning and code-step dynamics are handled in the next tuning-focused section.

Tuning f0 and Q (Control laws, ranges, monotonicity, and step behavior)

Electronic tuning becomes engineering-relevant only when the control knobs map to measurable outcomes. In a Gm-C filter, f0 is mainly set by gm/C and Q is set by gm ratios and feedback strength. Tuning must be specified not only by range and resolution, but also by monotonicity and code-step settling.

Tuning panel (knobs)
f0 knob
Method A: tune gm (bias current, DAC/code).
Method B: tune Ceff (cap bank, MOSCAP/varactor).
Watch-out: gm tuning also shifts linear range and noise; C tuning adds parasitics and step glitches if not sequenced.
Q knob
Tune Q via gm ratios and feedback coefficients; optionally sharpen poles using Q enhancement (effective negative resistance). Watch-out: Q enhancement consumes stability margin and can create burst oscillation or code-sensitive peaking.
Gain knob (optional)
Used to keep the passband level consistent across modes and avoid overload at high-Q settings. Keep gain tuning coupled to headroom limits and distortion verification, not only magnitude targets.
Tuning quality bars (must be specified)
  • Range: coverage with guardband (min/max f0, supported Q span).
  • Resolution: worst-case Δf0 and ΔQ per code step, not just typical.
  • Monotonicity: code increasing should not reverse f0 or produce Q “holes”.
  • Temperature repeatability: code-to-f0/Q curves should remain predictable across temperature.
  • Step behavior: settling after code steps (overshoot, tails, spurs during switching).
Practical contract (quick wording)
Specify “range + resolution + monotonicity + step settling” together. A wide range is not usable if code steps create spurs, non-monotonic segments, or long settling tails.
Dual-knob tuning for f0 and Q in Gm-C filters Block diagram: bias DAC controls OTA gm, cap bank controls effective capacitance, both feed a Gm-C filter core. Output goes to measurement and optional calibration/LUT closing the loop. Dual knobs: gm path + Ceff path (optional calibration loop) Bias DAC / Code gm tuning Cap Bank / Varactor Ceff tuning Gm-C Filter Core OTA C OTA gm Ceff Output Measure f0 / Q / noise Calibration / LUT (optional) closes loop vs PVT f0 knob Q knob Step behavior (settling/spurs) and monotonicity are first-class tuning specs, not afterthoughts.
A practical tuning implementation exposes two primary paths: gm tuning (bias/DAC/code) and Ceff tuning (cap bank/varactor). Measurement can drive an optional calibration loop to stabilize f0/Q across PVT.

Tuning side-effects checklist (each item includes a quick check)

1) f0–Q coupling
Symptom: tuning f0 changes peaking/ripple unexpectedly.
Quick check: sweep frequency at multiple codes; compare peak height and -3 dB bandwidth changes.
2) Q enhancement stability loss
Symptom: burst oscillation, long ringing, or mode-dependent instability.
Quick check: step tuning code and apply a small input step; verify decay without persistent oscillation.
3) Code-step spurs / glitches
Symptom: spurs appear during/after code updates; output “ticks”.
Quick check: run FFT while toggling codes; compare spur levels vs static-code baseline.
4) Slow settling / long tails
Symptom: code changes take long to settle; residual ripple persists.
Quick check: measure time-to-within-threshold after a code step (threshold set by system noise budget).
5) Non-monotonic segments
Symptom: f0 reverses direction or “holes” appear in Q across the code map.
Quick check: sweep full code range; flag any negative Δf0 or abrupt Q discontinuities.
6) Distortion varies strongly with code
Symptom: THD/IMD collapses at certain tuning settings (often high-Q or near headroom limits).
Quick check: compare two-tone IMD or single-tone THD at a few representative codes.
Selection cue

A tuning method is production-ready only if the code map is monotonic (or calibratable), code-step spurs are bounded, and settling meets the timing budget at worst-case Q and temperature.

Noise in Gm-C Filters (Input-referred, integrated noise, and source-Z interaction)

Noise evaluation should be done in the same units used by system requirements: in-band integrated noise (output RMS or input-referred RMS over the defined bandwidth). In baseband and low-frequency channels, 1/f noise and bias/reference injection often dominate, while wideband channels are more often limited by thermal noise and blocker-driven distortion.

Main contributors to track
  • OTA thermal noise: sets a wideband floor and scales with operating point.
  • OTA 1/f noise: becomes critical for low-frequency baseband and narrowband channels.
  • Bias / reference / code injection: noise or ripple from tuning circuits can fold into the passband.
  • CMFB-related noise: differential implementations add a common-mode control path that can leak into differential output.
  • Source impedance interaction: the source-Z sets how much input-referred noise is worth reducing with higher gm.
Noise river map for Gm-C filters Multiple noise source blocks feed into a Gm-C filter core. Output noise goes to an in-band integration block and is compared against a target threshold line. Noise river: contributors → output PSD → in-band integrate Source-Z OTA thermal OTA 1/f Bias/Ref CMFB Code inject Gm-C Filter OTA C OTA Output PSD In-band integrate RMS in BW Target threshold line Evaluate in the same bandwidth used by the system requirement: integrate the output PSD over the defined passband.
Treat noise as a budgeted resource: multiple contributors merge at the output, and the final check is the in-band integrated RMS over the defined bandwidth compared to the target threshold.

Noise budget workflow (target → allocate → verify)

Step 1 — Define the in-band target
Define bandwidth and measurement units (output RMS or input-referred RMS). Use the same passband used by the system SNR/ENOB requirement.
Step 2 — Allocate contributors
Allocate headroom for OTA thermal, OTA 1/f, bias/reference injection, and CMFB. Keep allocation stable across tuning codes and temperature.
Step 3 — Translate to integrated noise
Measure PSD and integrate over the defined passband. Compare the integrated RMS to the budget and identify which contributor dominates.
Step 4 — Verify across codes and temperature
Repeat the same noise test at representative tuning codes, two temperature points, and two load conditions. Noise must meet target in worst-case corners.
Measurement note (keep it production-realistic)

Noise should be measured with the real source impedance and the real passband definition. A “quiet” bench setup can hide bias/reference injection that appears under system-level grounding and code updates.

Source impedance interaction (when increasing gm is not worth it)

The optimal gm is set by which noise dominates in the defined passband. When source-related noise dominates, raising gm further often yields diminishing returns while increasing power and potentially worsening linearity margins. When OTA noise dominates, higher gm (or a different architecture) can meaningfully reduce in-band noise, but the distortion and headroom implications must be re-verified.

Quick check A — vary source-Z
Add a known series resistance (or switch source-Z) and re-measure in-band integrated noise. If noise tracks the source change strongly, the source dominates and gm increases may not pay off.
Quick check B — vary gm(code)
Hold source-Z constant and sweep a few gm codes. If noise improves strongly with gm, OTA noise dominates. If improvement saturates early, budget may be limited elsewhere (bias/reference/CMFB).
Section boundary note

Noise optimization should be finalized together with tuning behavior. Any tuning method that changes gm or injects code ripple must be re-validated using the same in-band integration definition.

Linearity & Distortion (IIP3, large-signal behavior, and Q-enhancement traps)

Continuous-time Gm-C filters can be tuned over wide bandwidth ranges, but linearity is often the first “hard limit.” The dominant failure modes are gm curvature, headroom-driven soft compression, and error amplification caused by high-Q peaking or Q enhancement loops. Linearity must be validated at worst-case codes, not only at typical settings.

Distortion evaluation workflow (keep it measurable)
  • Stimulus: single-tone (THD), two-tone (IMD/IIP3), optional multi-tone for blocker realism.
  • Sweeps: amplitude, tuning code, load condition (two known loads), and two temperature points (corner check).
  • Metrics: THD vs amplitude, IMD3 spur level, IIP3 (or equivalent intercept), compression behavior, overload recovery time.
  • Pass criteria: define thresholds in system units (e.g., spur < X dBc in-band; recovery < Y ms to within X%).
Core traps to anticipate
  • High-Q peaking: internal node swings increase even when input looks modest.
  • Q enhancement: improves selectivity but magnifies nonlinear error and consumes stability margin.
  • Differential ≠ immune: even-order terms can reappear via common-mode modulation and asymmetry.
  • Measurement baseline: source/fixture IMD can mask the DUT; baseline must be verified first.
Distortion paths and Q-enhancement traps in Gm-C filters Large-signal input passes through OTA gm nonlinearity producing THD and IMD. A Q enhancement loop amplifies error and can push compression or oscillation. Common-mode modulation can reintroduce even-order distortion in differential chains. Distortion paths: gm(v) + high-Q peaking + Q enhancement loop Large signal tone / 2-tone Gm-C Core OTA C gm(v) nonlinearity IMD3 / THD spurs in-band Compression Q enhancement loop error amplified risk: burst/osc CM modulation Validate at worst-case tuning codes: high-Q peaking raises internal swing and magnifies IMD/THD.
Distortion in Gm-C filters is usually driven by gm curvature and headroom limits. High-Q settings and Q enhancement can amplify error and reduce stability margin, making code-dependent “bad points” common.

Engineering cards (Symptom → Cause → How to measure → Fix direction)

A) IMD3 spikes at certain tuning codes
Symptom: IMD3 spur level jumps for a subset of codes at the same input level.
Cause: code-dependent peaking raises internal node swing; gm(v) curvature and headroom shrink dominate.
How to measure: two-tone test while sweeping codes; record IMD3 vs code at fixed input and fixed output levels.
Fix direction: constrain allowable input for high-Q codes, reduce passband peaking, or avoid unstable Q-enhancement regions.
B) Even-order distortion reappears in a differential chain
Symptom: HD2/IMD2 remains high and varies with VOCM, load, or asymmetry.
Cause: common-mode modulation and imbalance leak even-order terms into differential output.
How to measure: hold differential amplitude constant; sweep VOCM and one load condition; compare HD2/IMD2 sensitivity.
Fix direction: treat VOCM/load as part of the distortion contract; enforce symmetry and avoid CM-driven operating point shifts.
C) Q enhancement improves selectivity but worsens THD/IMD
Symptom: THD/IMD degrades sharply near the resonance/peak after enabling Q enhancement.
Cause: enhancement loop amplifies nonlinear error and reduces stability margin; peak gain increases effective swing.
How to measure: compare “enhancement off/on” at peak frequency: THD sweep vs amplitude + two-tone IMD check.
Fix direction: gate enhancement to necessary modes only, reduce peak gain, and add guardband to avoid code-sensitive instability.
D) Soft compression occurs before visible clipping
Symptom: spur levels rise and gain droops slightly even without hard rail clipping.
Cause: internal nodes saturate first; finite headroom and ro nonlinearity create early compression.
How to measure: sweep input amplitude; record gain compression and THD on the same sweep for multiple codes.
Fix direction: reduce internal swing (limit Q/peaking, reduce gain in high-Q modes) and re-validate overload recovery.
E) Overload recovery tail breaks timing budgets
Symptom: after a burst overload, residual ripple/spurs persist for a long time.
Cause: bias/CM paths and enhancement loops need time to return to nominal operating point; code steps can extend tails.
How to measure: apply a short burst; measure time to return within the system error threshold at worst-case codes.
Fix direction: define recovery as a first-class spec; constrain energy into the filter and avoid fragile high-Q code regions.
F) Measurement baseline (source/fixture) dominates the result
Symptom: distortion barely changes across DUT settings; results shift with cables/probes/instrumentation.
Cause: generator or fixture IMD and impedance mismatch sets the floor; DUT is not the limiting factor.
How to measure: measure baseline without DUT (or with a known linear bypass); verify headroom and impedance conditions.
Fix direction: document baseline verification in the test flow and ensure the measurement floor is well below the target.
Practical contract for production

Linearity is a mode-dependent contract. Verify THD/IMD/IIP3 and recovery at worst-case (high-Q, peak-gain, temperature corners) and lock the allowed input envelope per mode to prevent field failures.

Stability, PVT Drift, and Sensitivity (Why your Q/BW moves after tapeout/board)

“Simulation matches, hardware misses” is usually a sensitivity problem: gm drift, C drift, finite ro, parasitics, load variation, and CM/bias loop stability all move f0 and Q. The fastest way to converge is a structured checklist: sensitivity direction → control lever → verification point.

Sensitivity checklist (direction → control lever → verify point)
1) gm drift (process/voltage/temperature)
Direction: gm shift moves f0; gm ratio shifts move Q.
Control lever: segmented tuning and calibration tables to stabilize code-to-f0/Q across corners.
Verify point: two temperature points + representative codes; compare f0/Q drift vs budget.
2) C drift & Ceff tuning non-ideality
Direction: effective C shifts move f0 and can alter damping, hurting Q stability.
Control lever: minimize parasitic-dominated nodes; keep cap-bank switching monotonic and well-sequenced.
Verify point: full-code monotonicity scan; compare code-to-f0 curves under two known load/probe conditions.
3) Finite ro & load dependence
Direction: ro and load change effective damping; Q and peaking become mode- and load-dependent.
Control lever: treat load as part of the filter contract; avoid fragile high-Q operating points under heavy loads.
Verify point: re-measure f0/Q with two controlled loads; flag deltas exceeding the guardband.
4) Parasitics (routing C, input C, switch C)
Direction: parasitic capacitance effectively “adds C,” pushing f0 down and reshaping Q.
Control lever: identify high-impedance/integrator nodes and keep parasitics symmetric and budgeted.
Verify point: sensitivity experiment by adding a known small parallel C; compare predicted vs measured shift.
5) CMFB / bias loop stability
Direction: insufficient phase margin can add peaking, long recovery, or code-dependent tails.
Control lever: validate CM/bias loops as first-class loops; include load and mode changes in stability corners.
Verify point: code-step + disturbance test while monitoring differential and common-mode recovery separately.
6) Q enhancement margin across PVT
Direction: enhancement can cross into burst/oscillation in worst corners even if typical is stable.
Control lever: guardband the enhancement strength; gate enhancement by mode/temperature if necessary.
Verify point: worst-case corner sweep; enforce “no sustained oscillation” and bounded ringing criteria.
Sensitivity target for f0/Q drift in Gm-C filters Center shows f0 and Q. Six surrounding contributors (gm, C, ro, CMFB, parasitics, load) point toward the center, representing sensitivity drivers that shift frequency response after implementation. Sensitivity target: what moves f0 and Q after tapeout/board f0 Q gm C ro CMFB Parasitics Load Verify: sweep code + temperature + load (worst-case Q modes)
Treat f0/Q movement as a sensitivity problem. If gm, C, ro, CM loops, parasitics, and load are not included in the verification matrix, “simulation vs hardware mismatch” is almost guaranteed.

Fast convergence recipe (avoid long debug loops)

1) Lock measurement definitions
Define the passband, the Q extraction method, the load condition, and the tuning update procedure. A stable test definition prevents false “drift” diagnoses.
2) Build a minimal corner matrix
Use a small but representative matrix: two temperatures, two loads, and a few “high-risk” codes (highest Q, largest BW change, and code boundary points).
3) Separate f0/Q shift from instability
A stable but shifted response is typically gm/C/parasitics. Peaking, long tails, or burst behavior usually indicates CM/bias loop margin or Q enhancement margin issues.
4) Close the loop only after sensitivity is mapped
Calibration tables help only when sensitivity directions are understood and stable. If the dominant driver is mode-dependent instability, calibration will not fix the root cause.

Self-Calibration & Tuning Loops (Replica, FLL/PLL-assisted, background calibration)

Self-calibration is the mechanism that turns a tunable Gm-C filter from a “lab demo” into a repeatable, production-grade block. The practical goal is to keep the code-to-response mapping stable across temperature, supply, and aging by closing a loop on a measurable response feature (frequency peak, passband energy, bandwidth/Q proxy, or phase-related proxy).

Method map (choose by observability and repeatability)
A) Replica filter (background-friendly)
Use when: calibration must run without disturbing the main signal path.
Watch out: replica-to-main mismatch (parasitics/load/thermal gradient) can break coefficient transfer.
Minimum verify: compare main vs replica f0/Q at a few codes and two temperatures; confirm mismatch stays within LUT coverage.
B) Reference tone injection (peak/energy based)
Use when: a clean and repeatable feature exists (peak frequency, passband energy, or bandwidth proxy).
Watch out: injection spurs and measurement contamination by real signals; update must be gated.
Minimum verify: injection on/off FFT delta and detector SNR; confirm the update does not push spurs into the passband.
C) FLL/PLL-assisted (lock as a measurement engine)
Use when: frequency alignment must be robust across corners and modes, with automated tracking.
Watch out: update modulation (AM/FM) and loop chasing noise; loop bandwidth must be isolated from the signal band.
Minimum verify: sweep update rate/bandwidth; confirm update spurs remain below the in-band threshold.
Closed-loop self-calibration for tunable Gm-C filters Reference tone is injected through a gated injector into the Gm-C filter. A detector/ADC measures a response feature. A controller updates bias DAC and capacitor bank to align f0 and Q, verifies convergence, and stores coefficients. Self-cal loop: Inject → Measure → Update → Verify → Store Reference tone Injector / Mux Gate update Gm-C Filter Core OTA C Detector / ADC Controller Update code Bias DAC gm Cap bank Ceff Store Gate injection and updates so calibration does not introduce in-band spurs or mode instability.
A production-ready loop requires a stable observable feature, monotonic updates, and update gating. Coefficients must be versioned and stored with temperature tags and fallback behavior.

Calibration flow and deployment rules (foreground vs background)

Flow card (Inject → Measure → Update → Verify → Store)
Inject: use a known reference tone or a controlled stimulus; keep amplitude below the distortion threshold and above the detector floor.
Measure: extract a stable feature (peak/energy/bandwidth proxy); reject contaminated windows using a confidence metric.
Update code: use monotonic stepping (segmented search, bisection, or LUT + fine trim); rate-limit updates to avoid modulation.
Verify: confirm error is within thresholds (Δf0, ΔQ, and in-band spur limits) at the selected mode and load condition.
Store: save coefficients with temperature tags, calibration version, and a safe fallback mode if verification fails.
Foreground vs background
Foreground calibration: run in a quiet window (or bypass mode) for the cleanest measurement and fastest convergence; define explicit entry/exit gates.
Background calibration: use replica paths or low-duty injection while signals run; gate updates so spurs and settling do not land inside the signal band.
Production & field rules
Temperature points: calibrate at two or three representative points to cover drift curvature; store per-point coefficients or segmented LUTs.
Recal triggers: temperature step beyond threshold, supply change, entry into high-Q mode, self-test failure, or periodic aging refresh.
Fallback: if calibration confidence is low, fall back to a conservative mode (stable Q, bounded peaking) and log the failure bin.

Engineering Checklist (Design review + layout + bring-up tests)

This checklist is designed to prevent mode-dependent failures: non-monotonic tuning, Q-enhancement instability, code-update spurs, and load-sensitive f0/Q movement. The format is consistent: Check → Quick test → Pass criteria.

P0 (must pass before performance tuning)
□ Tuning monotonicity (full code sweep)
Quick test: automated sweep of f0/Q vs code; flag negative steps and boundary discontinuities.
Pass criteria: no reverse f0 steps; no “holes” where Q collapses or peaking exceeds the guardband.
□ Q-enhancement stability margin
Quick test: code-step and small disturbance response at worst-case codes and worst-case load.
Pass criteria: no sustained oscillation; ringing decays below the system error threshold within the timing budget.
□ Code update spurs and settling
Quick test: compare FFT for static-code vs step-code operation; monitor transient settling after updates.
Pass criteria: update-related spurs remain below the in-band spur limit; settling completes within the allowed window.
P1 (performance validation across risky modes)
□ In-band noise meets budget
Quick test: integrate in-band noise for representative codes; include bias/CM paths and detector chain if used in calibration.
Pass criteria: integrated noise stays below the system threshold for all required bandwidth modes.
□ THD / IMD / IIP3 at worst-case codes
Quick test: single-tone THD vs amplitude and two-tone IMD sweeps at high-Q and boundary codes.
Pass criteria: spurs remain below the distortion limit; compression and recovery meet the timing budget.
□ Load sensitivity guardband
Quick test: re-measure f0/Q under two controlled loads; compare code-to-response maps.
Pass criteria: deltas remain within the defined guardband for all required modes.
P2 (production and field robustness)
□ Calibration repeatability and versioning
Quick test: run the full loop twice; compare stored coefficients and achieved f0/Q under identical conditions.
Pass criteria: coefficients and achieved response remain within repeatability bounds; calibration version is recorded with temperature tags.
□ Safe fallback behavior
Quick test: force a low-confidence measurement; confirm the system enters a conservative stable mode and logs the event.
Pass criteria: no instability; output behavior remains bounded and recoverable.
Bring-up swimlane for Gm-C tunable filters Swimlane diagram showing the recommended bring-up sequence: layout check, power/CM validation, small-signal response, tuning sweep, distortion validation, and calibration verification, with production hooks attached. Bring-up swimlane: do not skip stages Layout check Power / CM Small-signal response Tune sweep Distortion THD / IMD Cal verify VOCM ok f0/Q map monotonic store/fallback Production hooks: injection point • bypass path • loopback • code sweep automation
A stage-gated bring-up sequence prevents false root-cause conclusions. Build the f0/Q map first, then validate distortion and calibration behavior at the risky modes.

Production fields (minimal dataset for traceability)

  • Identity: Device ID, lot, calibration version.
  • Conditions: temperature point, supply condition, load condition.
  • Mode: tuning code (f0/Q/gain if applicable) and enhancement enable state.
  • Measured: f0, Q proxy, in-band noise, THD (or IMD3), recovery time.
  • Calibration: stored coefficients (or LUT segment), pass/fail bin, fallback entry flag.
How to use this dataset

The dataset ties field failures back to specific modes and calibration states. It enables quick separation between sensitivity drift (gm/C/parasitics/load) and stability failures (CM/bias loop margin or Q enhancement margin).

Applications (Strictly within this page boundary)

This section provides reusable chain templates only (Goal / Constraints / Tuning strategy / Verification). The example part numbers are starting points for datasheet lookup—shortlisting must follow the inquiry fields in the next section.

Comms / RF Baseband (variable-BW channel-select)

Goal
Select bandwidth and reject adjacent interferers while keeping tuning updates from creating in-band spurs.
Constraints
  • Blockers: IMD3 under strong adjacent signals; code-dependent worst cases.
  • Updates: tuning steps must be gated to avoid AM/FM modulation and spurs.
  • Recovery: mode switches must meet settling and overload recovery budgets.
Recommended tuning strategy
  • Align f0 first, then trim Q inside a guarded stability envelope.
  • Apply update gating: measure continuously, update only in low-risk windows.
  • Prefer replica/background calibration if main-path disturbance must be minimized.
Verification
  • Two-tone IMD vs tuning code (include high-Q and boundary codes).
  • FFT delta for static-code vs step-code operation (update spur check).
  • Mode-switch settling and overload recovery time (time-domain envelope).
Example part numbers (starting points)
  • AD9361 (Analog Devices) — configurable mixed-signal transceiver with programmable baseband bandwidth/filtering blocks.
  • ADMV8818 (Analog Devices) — digitally tunable HP/LP filter (useful as a tunable filtering reference in RF/IF chains).
Notes: treat these as reference implementations; require conditions (code/temp/supply/load/amplitude) when comparing vendors.

Instruments / DAQ (tunable anti-alias LP and noise-bandwidth control)

Goal
Tune cutoff to match sampling plans, reduce aliasing risk, and narrow in-band noise while respecting phase/latency constraints.
Constraints
  • Group delay/settling: cutoff changes must not break step/impulse timing budgets.
  • Noise integration: integrated noise must track target SNR at each bandwidth.
  • Repeatability: code-to-fc mapping must be stable for automated scans.
Recommended tuning strategy
  • Tune fc to meet alias/noise-bandwidth targets; constrain Q to avoid excessive peaking.
  • Define a validated code set (allowed modes) rather than assuming all codes are usable.
  • Use periodic verification (or background calibration) if drift breaks the fc contract.
Verification
  • Magnitude + phase (or group delay proxy) at required modes.
  • Step response / settling after tuning updates (worst-case code boundary).
  • In-band noise integration vs bandwidth modes (budget check).
Example part numbers (starting points)
  • LTC1564 (Analog Devices) — digitally controlled continuous-time lowpass filter for antialiasing/reconstruction style use cases.
  • LTC1563-2 / LTC1563-3 (Analog Devices) — continuous-time monolithic lowpass filter family (cutoff set by resistor calculation).
  • LTC1562 / LTC1562-2 (Analog Devices) — quad universal continuous-time filter blocks (configurable f0/Q/gain via resistors).
Notes: for each candidate, require the measurement conditions (cutoff code/resistor, temp, supply, load, amplitude).

Multi-Standard AFE (profiles + PVT compensation)

Goal
Support multiple bandwidth/selectivity profiles with predictable behavior across temperature and supply using stored tuning maps and controlled recalibration.
Constraints
  • Profile switching: repeatable transitions without unexpected peaking or spurs.
  • Coefficient management: versioning, temperature tags, safe fallback rules.
  • PVT drift: profile maps must remain valid across specified corners.
Recommended tuning strategy
  • Use per-profile LUT/coefficients rather than one global mapping.
  • Trigger recalibration on temperature/supply thresholds; gate updates to prevent in-band modulation.
  • Define a conservative fallback profile to guarantee stability if calibration confidence is low.
Verification
  • Profile A/B/C: f0/Q targets, in-band noise, and distortion under defined conditions.
  • Profile switch transient: settling time and update spur limits.
  • Corner coverage: two temperatures and two loads for the risky profiles.
Example part numbers (starting points)
  • SLG47004 (Renesas) — configurable mixed-signal device used to implement adjustable analog filter behaviors in application notes.
  • AD9361 (Analog Devices) — programmable channel bandwidth and baseband filtering blocks (profile-like configurations).
Notes: require profile-to-code mapping details, update spur behavior, and corner drift characterization.
These templates highlight only the interface contracts and verification hooks that matter for tunable blocks.

IC Selection Logic (What to ask vendors + how to shortlist)

Shortlisting requires comparable data. For every key metric, demand the measurement conditions (tuning code or resistor/program value, temperature, supply, load, input level, frequency plan, and bandwidth definition).

Reference example part numbers (datasheet starting points)
OTA / gm building blocks
  • LM13700 (Texas Instruments) — current-controlled dual OTA used to build OTA-C / gm-C filters (validate linear range, noise, distortion vs bias).
Continuous-time tunable / programmable filters (monolithic)
  • LTC1562 / LTC1562-2 (Analog Devices) — quad universal continuous-time filter blocks; f0/Q/gain set by external resistors.
  • LTC1563-2 / LTC1563-3 (Analog Devices) — easy-to-use continuous-time lowpass filter family (resistor-set cutoff).
  • LTC1564 (Analog Devices) — digitally controlled continuous-time lowpass filter with programmable cutoff/gain.
Integrated programmable baseband filters (system IC)
  • AD9361 (Analog Devices) — configurable transceiver with programmable channel bandwidth and baseband filtering blocks (useful for profile-based tuning references).
Digitally tunable RF/IF filter module
  • ADMV8818 (Analog Devices) — digitally tunable HP/LP filter; useful when tunability and band selection are required at high frequencies.
Configurable mixed-signal (build adjustable analog filters)
  • SLG47004 (Renesas) — configurable mixed-signal device used in adjustable analog filter application notes.
What to demand from vendors (for every part number above)
  • Worst-case tuning codes (or resistor/program values) and monotonicity evidence.
  • Drift vs temperature and supply, plus repeatability across units/lot.
  • In-band integrated noise under defined source impedance and bandwidth definition.
  • THD/IMD (or IIP3) under defined amplitude/frequency plan and worst-case codes.
  • Update behavior: spur, settling, recovery, and any required gating rules.
Red flags (quick filters)
  • Q enhancement without stability guarantees across worst-case codes and corners.
  • Non-monotonic tuning or undisclosed unusable code regions.
  • Specs without conditions (no code/temp/supply/load/amplitude definition).
  • Update behavior not specified (spurs/settling/recovery missing).
Require measurement conditions and validate worst-case tuning modes before committing to a vendor shortlist.

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs (Gm-C / OTA-Tunable Filters)

Each answer is intentionally short and executable, using a fixed 4-line structure: Likely cause / Quick check / Fix / Pass criteria. Thresholds (X/Y/Z/T) must be set by the system budget and verified under defined conditions (code, temperature, supply, load, amplitude).

Why does tuned f0 drift after warm-up even with the same code?
Likely cause: Bias reference / gm temperature settling (self-heating) shifts gm-to-code mapping, moving f0 at a fixed code.
Quick check: Log f0 vs time after power-up at a fixed code (two input amplitudes); correlate with supply current and die/board temperature.
Fix: Add a warm-up guard time or a one-time post-warm-up calibration step; constrain early-time codes to a conservative set.
Pass criteria: After T minutes, f0 drift stays within ±X% over Y minutes at the specified temperature and supply.
Why is Q stable in simulation but peaking/oscillation happens on hardware?
Likely cause: Unmodeled parasitics and loading reduce phase margin in the effective loop, turning “high-Q” into peaking or oscillation at certain codes.
Quick check: Sweep Q-related codes and measure peaking ratio (|H|max/|H|passband) and ring-down in time-domain; test two load conditions (light vs actual ADC/load).
Fix: Reduce Q-enhancement gain (or cap Q max), restrict unstable code regions, and add controlled damping via allowable tuning/feedback settings.
Pass criteria: No sustained oscillation; peaking stays below +Y dB and step ring-down settles within T ms across worst-case codes and loads.
How can CMFB instability show up as passband ripple or slow recovery?
Likely cause: CMFB loop peaking or slow poles modulate the differential path, creating ripple, asymmetry, or long recovery after transients.
Quick check: Observe common-mode node (VOCM or output CM) during small-signal sweep and during a step/overload; look for CM ringing or slow return to nominal CM.
Fix: Increase CMFB stability margin by reducing CMFB loop gain at high frequency or slowing differential aggressiveness; avoid codes that push CMFB headroom.
Pass criteria: CM deviation stays within ±X mV and recovers within T ms; passband ripple change due to CM dynamics is < Y dB.
Why does THD get worse at some tuning codes but not others?
Likely cause: Code-dependent operating point changes gm linear range (headroom/ro) or Q-enhancement loop gain, amplifying nonlinearity at specific codes.
Quick check: Measure THD vs code at a fixed input frequency and two amplitudes; identify “hot” codes and check if they correlate with higher peaking or reduced headroom.
Fix: Exclude hot codes from the allowed set, derate input swing for those modes, or reduce Q-enhancement/loop gain in the affected code region.
Pass criteria: THD remains better than -Y dB (or < X%) across all allowed codes at the specified amplitude and load, with no unexpected code-only outliers.
Q-enhancement works but causes random “burst” oscillations—what to check first?
Likely cause: Marginal stability where noise, load steps, or code update glitches intermittently push the loop into oscillation (“burst” behavior).
Quick check: Capture time-domain bursts and correlate with (a) tuning updates, (b) load changes, (c) supply/bias noise; test with Q-enhancement disabled as A/B control.
Fix: Reduce Q-enhancement gain and add update gating (no updates during sensitive windows); restrict burst-prone codes and improve bias decoupling/isolation.
Pass criteria: Zero burst events over N minutes under worst-case code/load/supply noise tests; no sustained oscillation and recovery < T ms.
Why does the filter clip earlier than expected even with enough supply headroom?
Likely cause: Internal nodes saturate first (OTA output swing/ro limits or CMFB headroom), especially at high-Q or certain codes that increase internal signal swing.
Quick check: Measure THD or compression vs input amplitude at two Q settings; monitor output CM and look for asymmetry or sudden distortion increase before rail swing is reached.
Fix: Reduce Q or input swing in high-gain modes, adjust common-mode target to maximize headroom, and avoid codes that shrink internal linear range.
Pass criteria: 1 dB compression point (or clipping threshold) meets ≥ X Vrms at specified Q/code; CM stays within ±Y mV at maximum allowed amplitude.
Why does changing load / ADC input make the response shift?
Likely cause: Finite output resistance and load-dependent poles/zeros shift effective f0/Q; sampling kickback or input capacitance can alter the continuous-time response.
Quick check: Compare response with (a) high-impedance buffer load, (b) real ADC/load; measure the delta in f0/Q and any extra peaking or ripple.
Fix: Add a proper isolation/buffering stage (or increase allowable load impedance), and qualify a load envelope in the interface contract before final tuning maps are frozen.
Pass criteria: With specified load range, f0/Q shift stays within ±X% and passband ripple change < Y dB; no new peaking appears when the ADC is connected.
Why does the response change when probing with a scope/FET probe?
Likely cause: Probe capacitance/ground inductance adds parasitics, shifting poles and reducing stability margin, especially in high-Q modes.
Quick check: Repeat measurement with shorter ground spring or different probe capacitance; compare response change vs probe type and attachment point (output vs internal node).
Fix: Measure at buffered/defined test points and avoid probing sensitive high-impedance nodes; use consistent fixturing for production characterization.
Pass criteria: Response delta between approved probe setups is < X% in f0 and < Y dB in ripple; no probe-induced oscillation across allowed modes.
How do I verify tuning monotonicity without a VNA?
Likely cause: Non-monotonic code-to-gm/C mapping or code-dependent loading can create “holes” and reversals in f0 or peaking.
Quick check: Use a swept tone (or stepped multi-tone) and log peak frequency vs code; alternatively inject a reference tone near expected f0 and search the code that maximizes output (repeat for multiple bands).
Fix: Build an allowed-code table (validated modes) and map codes to f0/Q using measured points; avoid assuming linear code-to-frequency behavior.
Pass criteria: Peak frequency (or identified f0 proxy) is strictly monotonic across the allowed scan, with adjacent-step error < X% and no reversals under defined load and temperature.
Why does 1/f noise dominate even when in-band BW is not tiny?
Likely cause: Upconversion/mixing through nonlinearity, bias/reference noise coupling, or high low-frequency gain that weights 1/f components into the measured band.
Quick check: Measure noise PSD with (a) input shorted, (b) bias/reference quieted (extra filtering or alternate supply), and compare low-frequency slope; check code dependence and Q settings.
Fix: Improve bias/reference filtering and isolation, avoid modes that amplify LF gain unnecessarily, and qualify a noise-optimized code set for low-frequency operation.
Pass criteria: Integrated in-band noise meets < X Vrms (or < Y dBFS) and the 1/f corner stays below fC under defined bias and tuning modes.
How do I separate bias/reference noise from OTA noise in measurement?
Likely cause: Bias/reference noise modulates gm or CMFB, appearing as output noise that can be misattributed to OTA core noise.
Quick check: A/B test with extra bias filtering (or a cleaner bias source), then compare output noise PSD; also compare noise vs tuning code (bias-sensitive modes will move more).
Fix: Isolate bias/reference rails, add local decoupling and filtering near bias nodes, and specify bias noise limits as part of the tuning contract.
Pass criteria: With bias quieting applied, output noise reduction matches expectation (e.g., ≥ X dB in the suspect band) and residual noise stays within the OTA-only budget.
How to set calibration intervals across temperature without over-calibrating?
Likely cause: Calibration is scheduled by time rather than by drift observables, causing unnecessary updates and extra spurs or downtime.
Quick check: Build a drift curve (f0/Q error vs temperature and time) for worst-case modes; determine error growth rate and identify a measurable proxy (peak shift, gain error, CM drift).
Fix: Use event-based triggers (ΔT, Δsupply, detected f0 error) and only recalibrate when the proxy crosses a threshold; store per-profile coefficients with versioning.
Pass criteria: Calibration events per hour stay below N while f0/Q error remains within ±X% across the specified temperature range and load conditions.
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.