123 Main Street, New York, NY 10001

Submit Your BOM

Loop Bandwidth for Clock Cleaners & Trackers (PLL)

Loop Bandwidth for Clock Cleaners & Trackers (PLL)

← Back to:Reference Oscillators & Timing

Loop bandwidth is the single knob that decides which noise dominates (reference vs VCO), so it directly trades jitter attenuation, lock time, and stability/peaking. This page turns BW selection into a repeatable workflow: start from endpoint budgets, pick cleaner vs tracker behavior, then validate by measuring transfer, generation, and peaking with consistent windows.

Scope & boundary: what “loop bandwidth” decides (and what this page will NOT cover)

Loop bandwidth is the control knob that decides what the PLL follows and what the PLL rejects across offset frequency. This page treats bandwidth as an engineering decision tied to attenuation, peaking, lock time, and stability—not as a standalone “bigger/smaller is better” myth.

In-scope (this page owns)

  • Cleaner vs Tracker: bandwidth definitions, expected behavior, and “noise ownership” differences.
  • Hard coupling between bandwidth and jitter attenuation, jitter peaking, lock time, and loop stability.
  • A repeatable selection workflow: pick bandwidth from endpoint budgets, then validate with measurements.

Out-of-scope (use sibling pages)

Rule: topics below appear only as one-line pointers (no deep dive), to keep this page vertically focused.

  • Fractional-N spurs / DDS images → Spurs & Masks / PLL architecture pages.
  • LVDS/HCSL/LVPECL terminations & swings → Output Standards.
  • PSRR, isolation, supply filtering, EMI compliance → Supply & EMI.
  • JESD204 / PCIe / SyncE / PTP details → their interface-focused pages.

The knob being tuned: Follow vs Reject (3-line rule)

Follow (what passes)
Low-offset phase/frequency behavior that the loop tracks (reference drift, slow phase ramps, long-term alignment).
Reject (what is attenuated)
Offset bands where input noise is suppressed so output is dominated by the local oscillator (cleaner-like behavior).
Price (trade-off)
Lock time, stability margin, and jitter peaking risk move together—bandwidth cannot be tuned in isolation.
Noise ownership map for PLL loop bandwidth Block diagram showing reference noise and VCO noise contributions to output jitter, with low-offset and high-offset dominance arrows and a loop bandwidth marker. Noise sources → Output ownership Reference noise PLL loop bandwidth sets split VCO noise Output jitter / phase noise Low offset: output tends to follow reference High offset: output tends to follow VCO BW marker: where ownership shifts

Key framing: bandwidth moves the boundary between “follow” and “reject”. Cleaner designs push that boundary lower; tracker designs push it higher.

The mental model: noise shaping in one picture (reference vs VCO)

Two transfer behaviors explain most real-world outcomes. The reference-to-output path dominates on one side of the loop corner, while the VCO-to-output path dominates on the other side. Moving loop bandwidth shifts the crossover point and changes which noise source “owns” the output in each offset region. Cleaner-like designs emphasize rejecting incoming jitter beyond the corner; tracker-like designs emphasize following incoming phase and minimizing lock time.

Practical reading rule: if the output phase-noise curve starts resembling the reference shape over a wider offset span, the loop is effectively wider. If the output starts resembling the VCO floor/slope earlier, the loop is effectively narrower (or the loop gain is lower than expected).

PLL noise shaping: reference vs VCO transfer across offset frequency Illustration of two simplified transfer curves over offset frequency, with a loop bandwidth vertical marker indicating the crossover where output ownership shifts. Offset frequency → Gain (relative) BW corner Ref → Output transfer VCO → Output transfer Ownership shifts around BW Interpretation: wider BW → more ref passes; narrower BW → more VCO dominates sooner

Remember these 3 rules

  1. Below the corner, output behavior trends toward reference-following; above the corner, output trends toward VCO-dominated.
  2. Moving bandwidth changes where each noise source dominates; it does not remove the trade-off—noise is redistributed across offset.
  3. Bandwidth must be chosen together with damping / phase margin; otherwise jitter peaking and unstable lock behavior appear near the corner.

Definitions that matter: BW, natural frequency, damping, order (so we speak the same language)

“Loop bandwidth” is often used to describe different quantities. To avoid mismatched expectations and measurement debates, each bandwidth reference must state its definition and how it is measured. Practical loop behavior also depends on damping / phase margin and the loop order (extra poles/zeros, delays).

Bandwidth terms: what they mean in practice

BW(3 dB) · closed-loop magnitude
How to measure
Small-signal sweep of a closed-loop response; find the −3 dB point relative to low-offset gain.
Common confusion
The −3 dB point is not always the “ownership shift” point for noise; damping and order can move the apparent corner.
Bn · noise bandwidth (equivalent)
How to measure
Compute from the transfer magnitude area (tool/model), or report directly from vendor software.
Common confusion
Bn can differ from BW(3 dB). Mixing them breaks RMS jitter comparisons and “before/after” claims.
fUG · unity-gain crossover (loop gain)
How to measure
Loop-gain analysis (model) or injection-based measurement; identify where loop gain crosses 0 dB.
Common confusion
fUG is not a drop-in substitute for closed-loop BW; extra poles/zeros and delay change closed-loop behavior.
fc · closed-loop corner (ownership crossover)
How to measure
Compare Ref→Out and VCO→Out transfer trends; locate the crossover region where dominance shifts.
Common confusion
The crossover is a region, not a single point. Reporting without the window/context creates false disagreements.

Second-order intuition: ωn, ζ (damping), phase margin → what the scope shows

  • Natural frequency (ωn): sets the response speed scale (how quickly the loop can correct phase error).
  • Damping (ζ): controls overshoot and ringing; low ζ increases jitter peaking risk near the corner.
  • Phase margin (PM): frequency-domain safety margin; reduced PM often appears as peaking and long settling.
  • Higher-order loops: extra poles/zeros and digital delay can shift effective BW and degrade PM; use model + measurement rather than intuition.
Step response vs damping ratio (zeta) Three simplified step responses for the same loop with zeta 0.3, 0.7, and 1.2, highlighting overshoot and settling behavior. Step response vs damping (ζ) Time → Response Final value ζ = 0.3 ζ = 0.7 ζ = 1.2 Overshoot Settling

Reporting rule: whenever “bandwidth” is stated, the term must be labeled (BW(3dB), Bn, fUG, or fc) and tied to a measurable method. Damping and order must be treated as co-parameters; otherwise a “correct BW” can still produce peaking and long settling.

Cleaner vs Tracker taxonomy: when you want a narrow loop vs a wide loop

Bandwidth selection starts with a single classification: is the loop meant to clean incoming jitter or to track input phase/frequency quickly? These goals produce different “acceptable outcomes” across offset frequency and different failure signatures in the lab.

Comparison: goals, rejects, tolerances, failure signatures

Cleaner Narrow BW (X Hz–Y kHz)
Goal
Isolate high-offset input jitter so the output is dominated by a local low-noise source.
Reject (prioritized)
Incoming reference noise beyond the corner; sensitivity to “dirty” upstream clocks.
Tolerate
Longer lock time; reduced trackability for slow drift (must be handled by system strategy).
Failure signature
Lock is slow or fragile across temperature; slips during holdover/switchover; “clean output” but poor drift tolerance.
Tracker Wide BW (X kHz–Y MHz)
Goal
Follow input phase/frequency quickly; minimize phase error and lock time under drift or frequency offsets.
Reject (prioritized)
Low-offset VCO drift and long-term phase error; maintain tight tracking to the reference.
Tolerate
More input noise passes to the output; upstream reference quality becomes a system limiter.
Failure signature
Lock is fast but output jitter is worse; peaking appears near the corner; endpoint margins collapse despite “good lock.”

Common misconception: fast lock ≠ low jitter

A wider loop can reduce lock time while increasing the amount of reference noise that reaches the output. Classification must be based on the intended noise ownership and the endpoint jitter budget—not on lock time alone.

Cleaner vs Tracker taxonomy: narrow loop vs wide loop Two stacked block diagrams comparing a clock cleaner with a narrow loop bandwidth and a tracker/synth with a wide loop bandwidth. Taxonomy by intent Cleaner REF input PLL loop Narrow VCO low-noise OUT clean Intent: reject incoming jitter beyond the corner; output dominated by local oscillator. Tracker REF input PLL loop Wide VCO tracks OUT aligned Intent: follow input phase/frequency; fast lock with smaller phase error, at the cost of passing more reference noise.

Classification rule: treat bandwidth as a system-level choice based on endpoint budgets and intended noise ownership. Spur mechanics, output standard details, and supply/EMI methods remain in their dedicated sibling pages and should be linked—not duplicated.

The trade-off triangle: attenuation vs lock time vs stability (and where peaking sneaks in)

Loop bandwidth tuning moves a system along a three-way trade-off. Narrower bandwidth usually increases input-jitter suppression but slows acquisition and reduces tolerance to frequency offset and drift. Wider bandwidth improves lock time and tracking but passes more reference noise into the output. Stability (damping/phase margin) decides whether the corner stays “quiet” or turns into a peaking hotspot.

Loop bandwidth trade-off triangle with peaking zone Triangle diagram showing attenuation, lock time, and stability as competing objectives, with a central peaking warning region near the corner. No free lunch: BW moves the compromise Peaking zone Attenuation Lock time Stability BW ↓ BW ↑ fast PM Rule: set endpoint budgets → pick BW range → then tune damping/PM (avoid peaking)

BW ↓ → more attenuation

  • Input jitter is suppressed over a wider offset region.
  • Lock time increases; trackability to frequency offset/drift decreases.
  • Lab symptom: output looks cleaner at high offset, but acquisition/slip issues appear under drift or temperature sweep.

BW ↑ → faster lock & tracking

  • Lock time improves; phase/frequency tracking strengthens.
  • More reference noise passes into the output.
  • Lab symptom: “fast lock” is achieved, but RMS jitter worsens and PN shape follows the reference over more offsets.

Where peaking sneaks in

  • Low damping / low phase margin near the corner produces a “bump” (jitter peaking).
  • Poor pole/zero placement or delay in higher-order loops amplifies corner sensitivity.
  • Lab symptom: ringing in step-like events, corner-region PN bulge, temperature/voltage corners trigger instability.

Engineering order (do not invert)

Endpoint budgets must be defined first. Bandwidth is selected as a range from those budgets. Damping/phase margin is then tuned to keep peaking under control. Optimizing lock time without this order often produces “fast lock but out-of-budget jitter” or “clean plots but fragile stability.”

How to pick BW from endpoint budgets (a step-by-step workflow)

Bandwidth selection becomes repeatable when it starts from endpoint requirements and a noise inventory. The workflow below treats bandwidth as a range (not a single magic number) and binds it to damping / phase margin targets and worst-case guardbands. Interface standards and supply/EMI techniques remain in their dedicated pages; this workflow focuses on the method.

Step 1 Endpoint requirement

Input: jitter window [fL,fH], phase-error tolerance, allowed wander/drift (X/Y placeholders).
Output: a single reporting and pass/fail basis for later comparisons.

Step 2 Noise inventory

Input: reference PN/jitter, VCO PN, distribution additive jitter, coupling paths.
Output: which noise dominates low/mid/high offset regions (method only).

Step 3 Choose ownership

Decision: prefer output dominated by VCO (cleaner) or dominated by reference (tracker) within the endpoint window.

Step 4 Initial BW range

If: reference is worse in a critical offset span → avoid passing that span directly.
If: VCO is poor at low offset → avoid making BW so low that drift dominates.
Output: BW = [X, Y] plus targets (peaking < X dB, PM > X° placeholders).

Step 5 Guardband & validate

Guardband: temperature, aging, reference switching, holdover worst cases.
Validate: simulate + measure; confirm jitter window and peaking/lock behavior meet pass criteria.

Budget-to-bandwidth workflow Flowchart showing a five-step process from endpoint requirements to validation, with an iteration loop back to update BW and damping. From endpoint budgets → BW range (repeatable workflow) Step 1 Endpoint window / tolerance Step 2 Noise inventory Step 3 Choose cleaner / tracker Step 4 Initial BW range + PM targets Step 5 Validate sim + measure Update BW + damping / PM guardband Iterate

Workflow output: a bandwidth range tied to measurable pass criteria (jitter window + peaking/PM targets) and guardbanded for worst-case conditions. This keeps “BW debates” concrete and prevents lock-time optimization from violating endpoint jitter budgets.

Stability & loop filter design: phase margin, zeros/poles, and why “works on bench” fails on board

Getting the “right BW number” is not the same as getting a stable loop. Phase margin and damping decide whether the corner stays quiet or turns into jitter peaking, ringing, and lock-time jitter. Board-level conditions amplify non-idealities: component drift, parasitic poles/zeros, and digital delay can reduce phase margin even when a bench setup looks fine.

PM / damping → what shows up

  • Low PM → corner peaking, sensitive stability across PVT.
  • Low damping (ζ) → ringing / overshoot, longer settling.
  • Extra poles / delay → bench pass but board/temperature fail.

Common instability sources (in-scope)

  • Charge pump non-idealities (dead zone, mismatch, leakage) → effective gain shifts.
  • Loop filter capacitor leakage/DA/tempco/biasco → zeros/poles drift.
  • KVCO / KPD deviations → BW and PM drift from the design point.
  • Digital quantization / update rate → equivalent phase delay and limit cycles.

Validation actions (repeatable)

  • Open-loop / closed-loop injection to measure loop gain and PM.
  • Sweep and extract jitter transfer + peaking near the corner.
  • Step-like disturbance response: ringing, overshoot, settling time.
  • Repeat across temperature/voltage to confirm guardband.

Symptom → likely cause → first probe

Corner “bump” / peaking
Likely cause
Low PM or drifted zeros/poles.
First probe
Measure jitter transfer near the corner; check PM via injection.
Ringing / long settling
Likely cause
Low damping (ζ) or extra pole/phase delay.
First probe
Step response proxy (switch/disturbance); confirm loop gain roll-off.
Bench OK, board fails on PVT
Likely cause
KVCO/KPD drift or capacitor bias/temp effects; digital delay margin loss.
First probe
Log Vtune vs temp; re-extract BW/PM across corners.
Bode plot with phase margin and peaking annotation Magnitude and phase sketches showing 0 dB crossing, phase margin (PM), and a peaking bump near the corner that indicates low damping or low PM. Stability view: 0 dB crossing, PM, and peaking near the corner Magnitude 0 dB peaking f Phase PM

Practical rule

Bandwidth is a target range. Phase margin and damping are the guardrails. Any non-ideality that shifts zeros/poles or adds delay can reduce PM and create peaking. Validation must include injection / jitter transfer checks and must be repeated across temperature and voltage corners.

Practical constraints that bound BW: fPFD limits, divider ratios, delay, and implementation ceilings

A desired bandwidth is not always physically achievable. The feasible range is bounded by update rate (fPFD), digital delay, and divider ratios that reshape loop gain. Pushing BW upward can be delay-limited or noise-limited; pushing BW downward can become drift-limited and can increase sensitivity during switchover/holdover events.

Upper bounds (implementation ceilings)

  • Update-rate bound: BW ≤ fPFD / X (placeholder rule).
  • Delay bound: BW ≤ 1 / (Delay · X) to protect PM.
  • Divider ratio N: changes effective gain/noise folding → re-check BW and PM when N changes.

Wide BW hidden costs

  • More reference noise passes to the output → higher input cleanliness requirement.
  • Higher sensitivity to digital delay and higher-order poles → PM can collapse.
  • Validation becomes more sensitive to setup and corner conditions.

Narrow BW hidden costs

  • Reduced tolerance to frequency offset and temperature drift (tracking-limited).
  • More sensitivity during switching/holdover scenarios (system strategy required).
  • Longer acquisition and potentially larger phase error under slow wander.
BW feasible region vs update rate Plot showing bandwidth feasibility bounded by delay-limited and noise-limited regions, with a central feasible window and a target BW marker. BW feasibility: ceilings and limits fPFD / update BW delay-limited noise-limited feasible Target BW low high

Decision order (constraints-first)

  • Check ceilings first: update rate, delay, and N-dependent gain set the BW upper bound.
  • Use endpoint budgets to choose a BW range and cleaner/tracker intent.
  • Lock PM/damping targets, then validate across corners with jitter transfer and step-like tests.

Measurement & validation: how to prove BW, attenuation, and peaking (without fooling yourself)

Validation must separate three proofs: loop BW, jitter transfer (ref→out), and jitter generation (intrinsic/VCO-related). Mixing these metrics, changing integration windows, or letting instrument floor shape the curve leads to confident but wrong conclusions. A robust procedure fixes the window, fixes the setup, and changes only one variable at a time.

Proof #1 — loop BW

  • Method: small-signal closed-loop response / injection.
  • Output: corner location and repeatability across PVT.
  • Pass: BW ∈ [X, Y], drift < X% (placeholders).

Proof #2 — jitter transfer (ref→out)

  • Method: controlled ref disturbance or equivalent injection.
  • Output: attenuation vs offset + peaking near the corner.
  • Pass: transfer ≤ X dB in window; peaking < X dB.

Proof #3 — jitter generation (intrinsic)

  • Method: lock to a clean ref; compare across BW settings.
  • Output: output floor that does not follow ref changes.
  • Pass: generation aligns with budget (X fs / X dBc/Hz placeholders).

Common traps (and quick sanity checks)

Instrument floor shaping
If far-offset PN “flattens” abruptly or changes with range/averaging, confirm the analyzer floor first. Target: measurement stays > X dB above floor (placeholder).
Integration window mismatch
RMS jitter depends on [fL, fH]. Use one fixed window and annotate it everywhere. Comparisons are valid only when the window is identical.
Gate/trigger “fake peaking”
If a peak moves or changes strongly with gate width/trigger/averaging, treat it as suspicious. Cross-check with a second gate setting and a second instrument mode.

Acceptance rule (one-variable comparison)

Fix the setup and the window first: same source, same load, same cabling, same instrument settings, same [fL,fH]. Change only one knob (BW or damping) and verify directionality across all three proofs: BW shift, transfer shape, and generation floor.

Verification use-case matrix (setup → observation → expected direction)

Use-case A — BW change
Input: identical ref, BW1→BW2
Observe: BW proof + transfer corner
Expect: corner shifts; peaking should not increase beyond X dB
Use-case B — ref disturbance
Input: known ref modulation/injection
Observe: ref→out transfer in window
Expect: attenuation improves when BW narrows
Use-case C — clean-ref floor
Input: clean ref, fixed window [fL,fH]
Observe: output floor vs BW
Expect: generation-limited floor stops improving beyond a point
Measurement hookups: inject and observe Block diagram showing Ref input, injection, PLL loop, VCO, output buffer, observation nodes (Ref, Vtune, Out), and instruments (PN analyzer, scope, counter). Hookups: inject + observe (keep same [fL,fH] window) Ref source Inject PLL / loop CP LF VCO Out buffer Ref Vtune Out Phase noise analyzer Scope step proxy Counter freq / drift Window: same [fL, fH]

Design hooks & failure modes: lock is fast, but jitter is worse — what went wrong?

Fast lock does not imply a cleaner clock. A wide loop can hand noise ownership to the reference and increase output jitter inside the endpoint window. Instability and non-linearity can also make jitter intermittent: drifted loop gain, capacitor behavior across PVT, or charge-pump dead-zone effects. The cards below use a consistent pattern: symptom → quick check → reversible test → fix direction.

Fast lock, worse jitter

Quick check: ref→out transfer is higher in the jitter window.
Reversible test: narrow BW slightly; jitter should improve if transfer-dominated.
Fix direction: confirm cleaner/tracker intent; avoid passing the “bad ref” offset span.

Jitter is inconsistent

Quick check: log Vtune vs time/temp; re-extract BW/peaking across corners.
Reversible test: shift BW up/down and observe whether the floor or transfer moves.
Fix direction: address drift sources (KVCO/KPD, loop filter behavior, CP non-idealities).

Peaking on some boards only

Quick check: compare loop gain/PM via injection and key component values.
Reversible test: adjust damping/BW slightly; peaking sensitivity indicates margin loss.
Fix direction: increase PM/damping margin; reduce pole/zero sensitivity to tolerance.

Bench OK, system fails

Quick check: repeat proof #1/#2/#3 with the same window and fixed hookups.
Reversible test: freeze setup; change only BW; verify directionality (transfer vs floor).
Fix direction: enforce a single protocol; treat system additive jitter as a budget item.

Peaking after a small BW tweak

Quick check: check delay/update-rate ceiling and higher-order poles.
Reversible test: step BW back; peaking drop suggests a delay-limited boundary.
Fix direction: respect feasibility bounds; redesign loop filter for PM under delay.

Lock-jitter / limit-cycle signs

Quick check: Vtune shows steps or periodic motion; jitter varies with tiny perturbations.
Reversible test: nudge BW/damping; periodicity moving with settings indicates non-linearity/quantization.
Fix direction: avoid dead-zone regimes; increase effective linearity and reduce quantization sensitivity.

Symptom → causes → first probe Cause-map diagram connecting common symptoms (fast lock worse jitter, drift, peaking on some boards) to cause clusters (BW too wide, BW drift, non-linearity, pole/zero shift, delay) and to first probes (transfer, Vtune log, loop gain/PM). Cause map: symptoms → cause clusters → first probe Fast lock worse jitter Jitter drifts Peaking some boards BW too wide noise ownership BW drift KVCO / KPD / C Non-linearity CP dead-zone Pole/zero shift parasitics / delay Probe jitter transfer Probe Vtune log Probe loop gain / PM

Minimal reversible experiment (fast diagnosis)

When the symptom appears, change BW slightly in both directions under the same window and setup. If output follows transfer shape, the issue is ownership/transfer. If output floor does not move but instability/peaking changes sharply, the issue is margin, poles/zeros, or delay ceilings. Record the directionality as the first diagnostic signature.

Engineering checklist (bring-up → validation → production guardband)

This section turns loop bandwidth (BW) decisions into repeatable gates: what to do, what to observe, what to record, and what to accept. Each line is written to be copy-pasted into an internal test plan without pulling in supply/EMI or interface-standard details.

A

Bring-up gates (make “LOCK=1” meaningful)

  • Config sanity (read-back)
    Do: read back BW/loop-filter/mode/reference selection registers. Record: full register dump + config version tag. Pass: dump matches design template; any delta has a tracked rationale.
  • Define lock criteria (beyond a status bit)
    Observe: frequency/phase error trend + control node (Vtune or equivalent). Record: “lock rubric” table. Pass: after lock, drift < X (your budget) for X seconds; control node stays away from rails.
  • First BW + peaking spot-check
    Do: quick closed-loop response or injection around the expected corner. Record: BW estimate + peak magnitude near BW. Pass: BW ∈ [X, Y]; peaking < X dB (your limit).
  • Temperature sampling (early, minimal)
    Do: measure at room + at least one corner (cold or hot). Record: BW/peaking/lock-time delta. Pass: BW drift < X%; lock-time stays within your system envelope.
B

Validation gates (prove transfer & generation)

  • Jitter transfer (ref → out), fixed reporting window
    Do: capture transfer magnitude across offsets that matter to the endpoint. Record: [fL,fH] + instrument settings. Pass: attenuation meets your target; peaking stays < X dB.
  • Jitter generation (intrinsic floor)
    Do: measure output noise/jitter with a “clean input” setup. Record: baseline PN/floor in the same [fL,fH]. Pass: floor ≤ X (your budget) and stable across repeats.
  • PVT margin check (BW & peaking drift)
    Do: repeat BW/peaking at temperature corners and with realistic divider/VCO settings. Record: worst-case deltas. Pass: worst-case still meets transfer + floor budgets.
  • Event robustness (switch/holdover), measured as waveforms
    Do: simulate ref switching / short ref loss / recovery. Record: phase transient + settle time. Pass: phase step < X and recovery < X (your system envelope), with no false alarms.
C

Production gates (freeze + guardband + fast pass/fail)

  • Parameter freeze (EEPROM / register image)
    Do: define what is fixed (BW/loop filter/mode/switch rules) vs allowed to vary. Record: production image + version control. Pass: post-program read-back matches exactly.
  • Guardband from distributions (lot + temperature)
    Do: collect BW/peaking/floor distributions across lots and temps. Record: guardband table. Pass: P99 (or worst-case) remains inside your acceptance limits with margin X%.
  • Fast test proxies (seconds, not hours)
    Do: choose a small set of production-friendly observables (lock time, frequency error, a fixed-offset phase noise point, event response). Record: pass/fail script. Pass: every check has a hard threshold X.
Deliverables pack (what “done” looks like)
  • Register/config image + version tag
  • BW + peaking report (fixed [fL,fH] and settings)
  • Jitter transfer + jitter generation baselines
  • Event tests: switch/holdover waveforms + limits
  • Production guardband table + fast-test pass/fail script
Bring-up to production gates for BW and jitter Three-stage gated workflow: bring-up, validation, and production, with artifacts and fail loops. Gated flow: Bring-up → Validation → Production Each gate has an observable + an artifact + a pass limit (X = your budget). Bring-up Validation Production Gate A1 Config read-back Artifact: reg dump Gate A2 Lock rubric Limit: drift < X Gate A3 BW + peaking spot Limit: peak < X dB Gate B1 Jitter transfer Artifact: plots + [fL,fH] Gate B2 Jitter generation Limit: floor ≤ X Gate B3 PVT drift check Limit: worst-case OK Gate C1 Freeze image Artifact: EEPROM/reg set Gate C2 Guardband Limit: margin ≥ X% Gate C3 Fast test Pass/fail: seconds Fail loop: If peaking / drift / floor fails → adjust BW regime or damping → re-run the previous gate with the same [fL,fH] and settings.

Applications & IC selection notes (placed BEFORE FAQ)

The goal here is not to re-teach interface standards. Instead, each scenario gives a BW bias, the main trade-off, the top risks, and the first probe that confirms whether the chosen BW regime is helping or hurting.

SerDes / PCIe-style links

BW bias: Mid→Wide
Why
Lock time and tracking of phase/frequency error often dominate; the loop can be pushed wider if the upstream reference is clean enough.
Top risks
  • BW too wide: reference noise leaks into the endpoint jitter window.
  • BW too narrow: poor tolerance to drift / reference wander; marginal lock margin.
  • Unexpected peaking near BW inflates integrated jitter even if “lock looks fine.”
First probe
Measure ref→out transfer with a fixed [fL,fH]; check peaking at the corner before optimizing for faster lock.

JESD-style converter clocks

BW bias: Narrow
Why
Random jitter windows and SNR budgets tend to favor attenuation of upstream reference noise; “cleaner-ish” behavior is often preferred.
Top risks
  • Peaking near BW causes integrated jitter to rise even when far-offset PN looks improved.
  • BW too narrow: drift/wander tolerance becomes fragile during switching/holdover events.
  • Comparing jitter numbers with different [fL,fH] hides real regressions.
First probe
Measure integrated jitter with the same [fL,fH] before/after BW changes, and correlate with transfer peaking.

Timing / sync (holdover & switching)

BW bias: Adaptive / Mid
Why
The loop is often asked to behave differently across modes (normal tracking vs holdover vs switching). A fixed BW can be a compromise; adaptive BW may reduce operational pain.
Top risks
  • BW too narrow: recovery is slow; switching events cause longer transients.
  • BW too wide: upstream noise is imported into short-term performance.
  • PVT drift moves BW → previously safe margins disappear in the field.
First probe
Run event tests (switch / short loss) and measure phase step and settle time against limits X.

Video / audio (user experience)

BW bias: Mid (tuned)
Why
Switching/lock time must be acceptable while keeping jitter artifacts below perceptual thresholds; BW is tuned to balance both.
Top risks
  • Fast lock achieved by widening BW but jitter becomes worse (noise ownership moved to the input).
  • Board-to-board variability pushes peaking above the limit only on some units.
  • Measurement setup changes (window, gating) create false “wins.”
First probe
Do a reversible experiment: narrow BW vs widen BW and check the direction of integrated jitter and lock time under the same settings.

IC selection notes (by category) — concrete part numbers

Part numbers below are starting points to speed up datasheet lookup. Final selection must be driven by your BW regime, [fL,fH] reporting window, switching/holdover needs, output formats, and production guardband plan. Always verify suffix, package, temperature grade, and availability.

1
Jitter attenuator / clock cleaner
2
Tracker / network sync (wider BW regimes)
  • TI LMK05318 — network synchronizer clock Orderable example: LMK05318RGZT
  • TI LMK05318B — revision/pin-compatible option in the same family
  • Renesas 8A34001 — system synchronizer (supports jitter attenuation & timing features) Orderable example: 8A34001PB-000AJG
3
Any-frequency clock multiplier (attenuation-capable)
4
Selection hooks (tie back to BW)
  • BW range & step: can the device actually hit your target regime without delay-limited instability?
  • Peaking control: does it offer damping/PM knobs and clear transfer curves?
  • Holdover/switch: does it define event behavior and provide alarms/telemetry?
  • Production plan: is there a robust way to freeze configs and test proxies quickly?
Decision tree: choose a BW regime Flowchart that uses endpoint jitter budget, lock time, holdover/switching, and reference cleanliness to choose narrow, mid, wide, or adaptive loop bandwidth. Decision tree: application → BW regime Keep the same jitter window [fL,fH] when validating changes. Start: endpoint jitter budget tight? Tight random jitter window favors attenuation YES NO Choose: Narrow BW Cleaner-leaning regime Need fast lock / tracking? YES NO Choose: Wide BW Tracker-leaning regime Switching / holdover critical? YES NO Choose: Adaptive BW Mode-aware behavior Choose: Mid BW Tuned compromise Validate with transfer + generation + event tests, using the same [fL,fH] and one-variable changes.

Official references (starting points)

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

FAQs (10–12) — loop bandwidth, peaking, stability, and validation

These FAQs close common debug loops without expanding the main body. Each answer is a fixed, testable 4-line structure with budget placeholders (X).

Why does widening loop bandwidth improve lock time but worsen output jitter?
Likely cause
A wider loop passes more reference noise into the output in the offset band that dominates the RMS jitter window, and/or increases peaking near the corner.
Quick check
Compare ref→out transfer and integrated jitter using the same [fL,fH] and identical analyzer settings before/after the BW change; inspect peaking near the corner.
Fix
Reduce BW or move the corner away from the sensitive offset band; increase damping to suppress peaking; improve upstream reference cleanliness if a wide BW is required.
Pass criteria
Lock time < X ms and integrated jitter in [fL,fH] ≤ X (your budget), with peaking < X dB.
My phase noise plot looks better, but RMS jitter got worse—what bandwidth/window mismatch should I check first?
Likely cause
The “better” region is outside the RMS jitter integration window, or the two results used different [fL,fH], gating, spur treatment, or instrument weighting.
Quick check
Re-integrate both PN curves over the same [fL,fH] with the same spur include/exclude rule and the same units; confirm identical marker offsets and averaging.
Fix
Standardize one reporting window per endpoint; track low-offset and high-offset KPIs separately; tune BW based on the window that actually matters.
Pass criteria
With fixed [fL,fH], RMS jitter improves (or stays ≤ X), and the direction matches the PN change within that same window.
I see a “jitter peaking” hump near the loop corner—what’s the fastest way to confirm damping/PM is the issue?
Likely cause
Insufficient damping / phase margin around the unity loop gain region, often from loop filter zero/pole placement or higher-than-expected loop gain.
Quick check
Make a small damping change (or a small BW shift) and observe whether the hump magnitude drops without moving far in frequency; a strong reduction is a damping/PM signature.
Fix
Increase damping (adjust zero/pole placement), reduce loop gain, or slightly reduce BW; verify KVCO and charge-pump current assumptions before finalizing.
Pass criteria
Peaking < X dB; step/settling behavior meets X ms and overshoot < X% (your limits).
Lock is stable at room temp but peaking appears across temperature—what component drift shifts the poles/zeros first?
Likely cause
Effective loop gain and time constants drift with temperature: KVCO drift, charge-pump current drift, loop filter capacitor TC/leakage/DA, resistor TC, and digital update-delay changes.
Quick check
Log BW and peaking vs temperature; watch the control node (Vtune / DCO code) for rail-hugging or slope changes; compare loop filter capacitor types if possible.
Fix
Use more stable loop-filter components (e.g., C0G/NP0 where feasible), increase phase margin, reduce sensitivity to gain drift, and add calibration/guardband to keep BW inside limits.
Pass criteria
Across temperature range, BW drift < X% and peaking < X dB, while lock behavior remains within X (your envelope).
Cleaner output looks great, yet the endpoint still fails—how to check if BW is letting reference noise through the wrong offset band?
Likely cause
The “great” measurement used a different [fL,fH] than the endpoint sensitivity, or the loop corner/peaking sits inside the endpoint’s critical offset band.
Quick check
Measure at the endpoint pin (or after the distribution path) and compute integrated jitter using the endpoint’s [fL,fH]; overlay the ref→out transfer curve to see what offsets are being passed.
Fix
Move BW corner away from the critical band, reduce peaking, and account for additive jitter in the distribution path; validate using the same window and measurement point used for endpoint acceptance.
Pass criteria
Endpoint passes functional margin; endpoint integrated jitter ≤ X in its [fL,fH], and transfer/peaking meets limits in the same band.
Narrowing BW reduced EMI issues but increased timing slips—what’s the first holdover/trackability sanity check?
Likely cause
BW became too narrow to track drift/wander or to recover from small disturbances, pushing the loop toward control saturation and slips during events.
Quick check
Log phase/frequency error and the control node during the slip; check whether Vtune/DCO code hits rails or whether error ramps exceed the loop’s trackable slope.
Fix
Increase BW slightly (or use adaptive BW), improve the local oscillator stability for holdover, and set event limits/alarms based on measured trackability.
Pass criteria
No slips over X duration and across temperature; phase error remains < X; control node stays within mid-range (not rail-hugging).
Two boards with the same BOM show different BW—what parasitics most commonly move the loop corner?
Likely cause
Loop-filter node parasitics and return-path impedance shift effective poles/zeros: trace capacitance at the CP node, via inductance, ground bounce, and coupling into the filter network.
Quick check
Compare BW/peaking on both boards; probe the loop-filter node ripple/noise; swap the loop filter network between boards to separate component tolerance from layout parasitics.
Fix
Tighten placement and return paths for the loop-filter network, reduce impedance at the CP node, add isolation where needed, and increase damping margin to tolerate parasitic variation.
Pass criteria
Board-to-board BW variation < X% and peaking spread < X dB, with consistent endpoint pass margin.
Why does enabling SSC break stability only on some units—how to test if BW/loop dynamics is the root? (See SSC subpage)
Likely cause
SSC adds modulation that excites marginal loop dynamics; parts with slightly worse damping/BW drift cross the stability boundary first (PVT/lot variation).
Quick check
A/B test SSC off vs on while logging lock status, phase error, and peaking; sweep BW narrower/wider and see whether failure boundary moves with BW (a loop-dynamics signature).
Fix
Increase damping margin, adjust BW so SSC modulation does not sit in the peaking region, and constrain SSC depth/rate per system tolerance (SSC mechanism details belong to the SSC subpage).
Pass criteria
With SSC enabled, no slips/unlocks across PVT; peaking < X dB; phase error < X and jitter remains ≤ X (your budget).
How do I measure loop bandwidth without a dedicated injection setup? (quick proxy checks)
Likely cause
Direct loop response is not available, so BW must be bracketed using proxies derived from transfer behavior and time-domain settling.
Quick check
Use one proxy: (1) locate the “knee” in ref→out transfer vs offset; (2) apply a small reference phase/frequency step and fit settling; or (3) inject a small FM tone on the reference and find the -3 dB tracking point.
Fix
Treat proxy BW as a bracket; confirm with a proper injection measurement on one golden setup; keep the same [fL,fH] and one-variable changes for all comparisons.
Pass criteria
Proxy BW matches the injection-based BW within X% on a reference unit and remains stable within X% across repeats.
Why does the PLL “hunt”/chatter near lock—dead-zone or too wide BW?
Likely cause
A limit cycle is forming: PFD/CP dead-zone or quantization creates small oscillation near lock, or BW is too wide with insufficient damping under real-board conditions.
Quick check
Observe the control node ripple and lock metrics while slightly reducing BW; if chatter collapses with a small BW/damping tweak, loop dynamics (not random noise) is the primary driver.
Fix
Increase damping and/or reduce BW, adjust PFD/CP settings to avoid dead-zone behavior, and set lock detect thresholds/hysteresis to match the new loop behavior.
Pass criteria
No repeated hunt cycles; phase error settles within X ms; control-node ripple < X and endpoint stability remains within budget.
Why does reducing BW improve high-offset PN but worsen low-offset wander/phase drift?
Likely cause
A narrower loop hands low-offset behavior to the local oscillator (VCO/VCXO/OCXO), increasing drift/wander, while high-offset PN improves due to less reference leakage.
Quick check
Compare low-offset PN and long-term phase/frequency error under the same conditions; integrate jitter with two windows (low-offset-heavy vs high-offset-heavy) to confirm which region dominates.
Fix
Increase BW until drift/wander meets the system tolerance, or upgrade the local oscillator quality; use dual-loop/disciplining or adaptive BW when both regions must be optimized.
Pass criteria
Low-offset drift/wander stays < X while the integrated jitter window that matters remains ≤ X (your budget), with no new peaking violations.
What’s a practical pass criterion for peaking (dB) and settling time (ms) for my system?
Likely cause
Peaking and settling limits are system-derived: they must map to the endpoint jitter window, event tolerance (phase steps), and production variability, not a universal rule-of-thumb.
Quick check
Derive limits from (1) endpoint integrated jitter budget (same [fL,fH]), (2) maximum allowed phase transient + recovery time, and (3) worst-case PVT/lot drift of BW/peaking.
Fix
Set two explicit gates: peaking < X dB and settling < X ms for a defined event; apply guardband < X% and enforce the same measurement setup in validation and production.
Pass criteria
Three-gate pass: (1) peaking < X dB across PVT, (2) settling < X ms for the defined event, (3) endpoint passes with margin ≥ X.
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.