Segmented DACs (thermometer MSBs + binary LSBs) exist to hit a practical “sweet spot”: strong linearity, low update disturbance, and useful speed—without the extreme area/power of a pure thermometer design.

This page shows how segmentation reduces worst-case switching events, where the true risk concentrates (the segmentation boundary), and how to validate the design with the right tests so that glitch, settling, and linearity are managed together rather than optimized in isolation.

Diagram focus: the left column is the design pressure, the center is the segmentation mechanism, and the right column shows where deeper sibling topics live to avoid scope overlap.

Definition

A segmented DAC splits its conversion elements into two coordinated regions: the MSBs use thermometer coding (many equal unit elements turned on in a contiguous way), while the LSBs use binary weighting (a small set of weighted elements for fine steps). Both regions sum at the output node to create the final analog level.

The architectural goal is not “maximum of one metric,” but a stable operating point where monotonic margin, worst-case switching disturbance, area/power, and update speed are simultaneously acceptable.

Two blocks, two jobs

The segmentation boundary is the engineering “risk concentrator”

Most metrics look excellent in typical conditions, but worst-case behavior often clusters near the boundary: combined switching, mismatch mapping, and code patterns that repeatedly stress the same elements. Future sections will treat boundary codes as a dedicated verification set rather than relying on averaged results.

Taxonomy (common variants, kept intentionally brief)

• Voltage-domain vs current-domain core: changes how switching errors appear at the output node and how the driver/load interact.
• Single-ended vs differential output: impacts even-order distortion rejection and common-mode control.
• Buffered vs unbuffered output: determines how much settling is dominated by external load and amplifier stability.
• Calibrated vs uncalibrated: determines whether mismatch becomes a trimmed coefficient or a residual static error.

Quick glossary (terms used throughout this page)

Diagram focus: the thermometer region reduces worst-case switching, the binary region preserves efficiency, and the dashed “boundary” line highlights where verification must concentrate.

Next section preview

The next step is choosing the segmentation split (thermometer bits vs binary bits) and defining a boundary-code test set so that linearity, glitch impulse, and settling are verified together.

Core mechanism (what actually sets glitch energy)

Update disturbance is dominated by three coupled factors: how many switches move, how well they move together (timing skew), and how much charge is injected into the sensitive output node. Segmentation works by reshaping worst-case transitions, so that large-weight decisions do not require many weighted switches to flip simultaneously.

Glitch impulse is not the same as “spike height”

A narrow spike can look small on a limited-bandwidth measurement while still delivering meaningful disturbance into a downstream amplifier, bias node, or control loop. That is why many datasheets and lab procedures focus on glitch impulse: an energy-like measure that captures how much transient charge is pushed into the output network during an update.

Why binary-only DACs suffer worst-case “major carry” events

• Some code transitions force many weighted switches to change state at once (carry propagation across multiple bits).
• Even tiny timing differences turn “simultaneous switching” into temporary imbalance at the output node.
• Charge injection and feedthrough from multiple switches add up, producing a measurable impulse and ringing that can dominate settling.

The key point is not that every update is bad—only that a small set of worst-case transitions can dominate system behavior and must be verified explicitly.

How segmentation reshapes worst-case switching

Boundary behavior still needs dedicated management

Segmentation does not eliminate risk; it concentrates it. Transitions that cross the segmentation split can combine switching activity from both regions. Boundary codes should be treated as a mandatory worst-case verification set (glitch impulse, large-step settling, and static linearity), not as something that will be “averaged out” by sweeping many codes.

Diagram focus: the goal is not “every code is perfect,” but “the worst-case transition becomes controllable,” with boundary transitions treated as a special test set.

Decision thesis

Segmentation is not chosen by resolution alone. It is chosen by worst-case behavior under the target update rate and load: select a split that keeps boundary transitions controllable while staying inside area/power limits.

The split moves five coupled dimensions

A practical four-step decision flow (structure first, algorithms later)

1. Start with the system target: required INL/DNL behavior and allowable update disturbance. If output transients directly impact a sensitive analog node, bias point, or loop stability, the split should bias toward more thermometer MSBs.
2. Add update rate and load: heavier loads and faster updates often shift the limiting factor to settling in the output network. The split must still keep boundary transitions controllable, but the system also needs adequate drive and clean return paths.
3. Check area and power budget: large unit arrays and decoding/drive overhead can dominate. If budget is tight, a larger binary region may be necessary, but only with a stronger worst-case verification plan.
4. Lock a boundary verification set: define boundary transitions as mandatory tests (static linearity + glitch impulse + large-step settling). Do not rely on a broad code sweep to “average out” worst-case behavior.

Diagram focus: the quadrant shows how the split shifts trade-offs, while the flow ensures boundary codes are treated as an explicit test set rather than averaged away.

What the metrics really mean in a segmented DAC

• DNL describes local step regularity. It is the metric that directly threatens missing codes and monotonic behavior.
• INL describes the global transfer-shape error. It becomes a setpoint accuracy and waveform amplitude error at the system level.
• Monotonic margin is a safety margin, not a boolean. It asks whether the smallest step still remains positive under temperature drift, noise, and load disturbance.

Mismatch maps differently in the thermometer region vs the binary region

Gradients turn “random mismatch” into systematic INL shape

Large unit arrays are vulnerable to thermal, IR-drop, and process gradients. Unlike purely random mismatch, gradients create repeatable, code-dependent structure: the same physical region contributes to a wide span of codes, making INL appear as a stable “shape” that can drift with temperature and supply conditions.

That is why linearity numbers are meaningful only when their measurement conditions (reference, supply, temperature, load) are matched to the intended application.

Switch non-idealities can masquerade as static linearity errors

• Code-dependent R_on / impedance changes the effective gain seen at the output node and can imprint a shaped INL error.
• Reference interaction (finite reference impedance and distribution) can convert switching-dependent current draw into code-dependent droop.
• Load interaction can make “linearity” vary with output swing and settling window, even if the core array is well matched.

A practical takeaway is to treat linearity errors as a system mapping problem, not only a device matching problem.

Boundary codes are where non-local error mapping shows up

Near the segmentation boundary, the thermometer and binary regions change contribution together. This can re-map mismatch and switch non-idealities into code bands that look “unexpectedly sensitive.” A small physical bias (gradient, reference droop, or switch impedance) can affect more than one adjacent code step, creating non-local behavior.

Because of this, boundary-adjacent codes should be treated as a mandatory static-linearity check set, not as a detail that will average out in a wide sweep.

Monotonicity: theoretical vs effective (under disturbance)

Diagram focus: static linearity is a mapping from physical sources into metrics, with boundary-adjacent codes often behaving as a dedicated sensitivity band.

Glitch impulse is an energy-like disturbance metric

Glitch impulse measures how much transient disturbance is injected during an update. It is not the same as settling time: a design can have a small impulse but slow settling (weak drive / heavy load), or a fast settling window but large impulse (strong simultaneous switching).

Typical sources (grouped by what they control)

Define a structural worst-case code set (do not average it away)

Major-carry: how the risk shifts in segmented DACs

In binary-only architectures, carry-related transitions can flip many weighted bits and create the largest impulses. Segmentation reduces this by assigning large-weight decisions to a thermometer-coded region. The resulting worst-case set often shifts toward boundary crossings and large-step patterns, which must be verified explicitly.

Control strategy (segmentation-related only)

• Use the thermometer region to reduce the number of high-weight simultaneous flips and lower typical worst-case impulse energy.
• Treat boundary codes as a dedicated verification subset (impulse + large-step settling + static linearity), not as a detail that will average out.
• When selecting the split, use worst-case code behavior as an input—not only typical specs or resolution targets.

Diagram focus: worst-case behavior clusters in structural hot zones; boundary and large steps must be verified as an explicit set rather than averaged across broad sweeps.

Three different time-domain phenomena

Why glitch can look small while settling is still poor

A segmented DAC can reduce worst-case simultaneous switching and therefore reduce the injected impulse, yet the output may still settle slowly if the external network dominates: R_out + C_load + driver loop set the dominant pole(s). In that case, the spike can be modest while the tail remains long, delaying entry into a tight error band.

Overshoot and ringing are usually not “segmentation problems”

• Driver stability under capacitive load can create underdamped behavior and long ring-down.
• Parasitic L and C in the output path can form resonances that dominate time-domain response.
• Return-path mistakes can inject ground bounce into the output reference point, turning a clean step into oscillation.

Compensation details belong in the driver design deep dive; here the focus stays on separating metrics and interpreting conditions correctly.

How to compare settling specs without being misled

Diagram focus: glitch impulse describes the update-edge disturbance, while settling is defined by an error band and conditions; ringing can violate the band long after the spike.

System reality: the output chain defines the delivered behavior

A segmented core can reduce worst-case switching behavior, but the system sees the combined chain: DAC core → buffer/driver → simple RC/LPF → load plus the reference and return paths. Many “DAC-looking” artifacts are dominated by this external network rather than by the coding method.

Why differential outputs tend to be more robust

• Even-order suppression improves distortion behavior when the external chain remains symmetric.
• Controlled common-mode reduces sensitivity to external coupling and reference noise injection.
• Return-path discipline is easier to enforce when the signal is carried as a pair with a defined reference structure.

Cload creates a common measurement illusion

Increasing load capacitance can make the glitch spike look smaller because the high-frequency content is filtered by the RC behavior. However, the same capacitance often worsens settling by lowering the dominant pole and increasing the demand on the driver loop.

Minimum output-chain guidance (keep it short and repeatable)

• Short current loops: minimize loop area from driver output to load and back to the reference return.
• Reference return is sacred: keep reference and output return paths clean and predictable.
• No digital return through the output reference point: prevent fast digital currents from crossing sensitive analog reference nodes.

Deeper driver compensation and filter design belong in dedicated topics; this section keeps only the levers that most strongly affect boundary and large-step behavior.

Diagram focus: the same core can look “better” or “worse” depending on return paths, reference distribution, and load; keep sensitive nodes clean and loops short.

Separate the metrics before blaming the core

• THD is dominated by harmonic generation (nonlinearity mapping).
• SFDR is dominated by the single largest spur (harmonic or non-harmonic).
• Code-dependent spurs are often created when a repeated code sequence modulates small static errors into discrete tones.

Common spur attribution paths (and what they imply)

Minimal isolation experiment set (change one variable at a time)

• Change code pattern (same amplitude): keep the same output swing while changing the sequence order and periodicity. Watch whether spurs move or vanish.
• Change update rate / sampling rate: check whether the spur follows the update process (location scales with f_s or its artifacts).
• Change clock cleanliness: adjust jitter/PLL/clock source and observe whether the floor or specific tones respond.
• Change load / driver configuration: observe whether harmonics or IMD change disproportionately with load or swing.

A reliable conclusion requires a controlled comparison. If code pattern and clock are changed together, the attribution becomes invalid.

Quick decision rules (pattern-bound vs clock-bound vs chain-bound)

Note on update shaping (kept intentionally brief)

Some DAC families offer update shaping options that alter spectral distribution. System-level RTZ/NRZ trade-offs belong to the current-steering / RF DAC deep dive and are not expanded here.

Diagram focus: isolate spurs by changing one lever at a time—sequence, then clock, then load/driver—until the spur clearly binds to a root cause.

Golden rule: if conditions are not comparable, results are meaningless

Record and lock: output configuration, load, bandwidth, window/threshold definitions, code pattern, and temperature state. Only then can data be compared across builds or devices.

Bring-up (establish a clean baseline first)

• Reference stability: confirm reference noise and return integrity before measuring linearity or FFT.
• Supply noise: verify analog/digital partitioning and decoupling effectiveness under update activity.
• Return paths: ensure fast digital return currents do not cross output/reference nodes.

INL/DNL (sweep strategy and repeatability)

• Sweep coverage: include full sweeps plus mandatory boundary-adjacent code coverage.
• Integration time: keep integration consistent across codes to avoid mixing noise with linearity.
• Thermal state: separate warm-up drift from static shape by controlling temperature and time.
• Repeatability: run multiple passes and confirm whether the INL “shape” is stable and reproducible.

Glitch impulse (make the measurement comparable)

Large-step verification (overshoot and settling criteria)

• Key step set: boundary crossings, MSB-step patterns, and extremes transitions.
• Overshoot criterion: check whether ringing crosses the defined error band and for how long.
• Settling criterion: verify enter-and-stay behavior to 0.5 LSB / 1 LSB / ppm under the documented condition set.

Dynamic FFT (tone choice and spur identification)

• Tone selection: avoid accidental periodicity that can create misleading sequence-bound spurs.
• Windowing consistency: keep window and record length consistent for comparisons.
• Spur isolation: apply the H2-9 flow (pattern → clock → load/driver) before concluding root cause.

Production strategy (risk-based: must-test vs sample-test)

Diagram focus: a repeatable test bench is defined by locked conditions and a structural worst-case subset (boundary, large steps, extremes), not by one-off “good-looking” plots.

Scope boundary

This section explains why segmented (thermometer + binary) DACs fit certain workloads and how to select parts by mapping fields to risks. It intentionally avoids scenario encyclopedias and keeps sync/interface implementation details as jump-outs to dedicated topics.

Applications (why segmentation fits, without expanding the universe)

Diagram focus: pick an application bucket, then verify the dominant requirement dimension and the external chain sensitivity; use jump-outs for sync/interface details.

IC selection logic (fields → risks → inquiry questions)

Diagram focus: the selection conversation stays productive when fields map to risks and every number includes comparable conditions.

How many thermometer bits are “enough” in a segmented DAC? +

Short answer: Enough thermometer bits are reached when worst-case update-edge disturbance is dominated by the output chain rather than by MSB simultaneous switching.

Why: Thermometer coding localizes large-weight transitions and reduces major-carry style “many-bit flip” events; beyond a point, load/driver settling becomes the limiter.

Check:

• Worst-case glitch/step occurs near boundary or large MSB transitions (not mid-scale only).
• Glitch impulse trends down as thermo bits increase, but settling stops improving.
• Boundary-adjacent DNL/INL hot zones remain controlled and repeatable.
• Area/power budget for unit elements + decoder remains acceptable.

Fix:

• Increase thermometer share if major-carry-like spikes dominate system error.
• Reduce thermometer share if decoder/array loading limits update rate or power.
• Always define a boundary-focused verification plan before finalizing the split.

Verify: Compare splits only under identical bandwidth, load, step size, and integration window; otherwise conclusions are invalid.

What makes boundary codes special, and why do they fail first? +

Short answer: Boundary codes concentrate structural risk because thermometer and binary segments can transition together, creating combined switching and non-local error mapping.

Why: Segmentation reduces large-scale switching in the MSB region, but the crossover zone can still create “compound” transitions and sensitivity to mismatch/gradients around the segmentation boundary.

Check:

• DNL/INL hot spots appear clustered near the boundary region.
• Worst-case glitch/overshoot aligns with boundary-crossing steps.
• Spurs strengthen when code patterns repeatedly visit boundary-adjacent codes.

Fix:

• Treat boundary transitions as a mandatory worst-case subset in validation and production screens.
• Prefer specifications that explicitly characterize boundary behavior instead of only “typical” figures.

Verify: Use the same code step set, measurement bandwidth, and load when comparing boundary results across parts or boards.

Which transitions should be the “mandatory worst-case set” for segmented DAC testing? +

Short answer: Always include boundary crossings, large MSB-equivalent steps, and extreme-end transitions; never rely on mid-scale-only tests.

Why: Worst-case switching energy and mapping sensitivity cluster around boundary and large steps; extremes often expose compliance and return-path sensitivity.

Check:

• Boundary-adjacent steps (both directions across the boundary band).
• Large-step patterns that emulate “MSB flips” at high weight.
• Extremes (near full-scale and near zero) under real load.

Fix:

• Define the worst-case set early and reuse it across bring-up, qualification, and production screening.
• Report both “typical” and “worst-case set” results; do not average boundary behavior away.

Verify: Worst-case sets are comparable only if step size, update rate, bandwidth, and load are identical.

Glitch impulse vs settling time: what is the difference? +

Short answer: Glitch impulse measures update-edge transient energy; settling time measures how long the output takes to enter and stay within a defined error band.

Why: A short spike can be small while the post-spike trajectory is slow (driver/load dominated), or vice versa; they are different mechanisms and must not be conflated.

Check:

• Glitch: bandwidth limit, integration window, trigger method, and code pattern.
• Settling: threshold (0.5 LSB / 1 LSB / ppm), step size, load, and “enter-and-stay” window.
• Whether the worst-case is boundary-crossing or chain-dominated.

Fix:

• Use glitch metrics to manage update-edge disturbance (especially boundary/large steps).
• Use settling metrics to meet sampling/loop timing constraints under real load.

Verify: A “better glitch” number is not meaningful if settling is measured under different thresholds or bandwidth.

Why can a smaller visible glitch still produce worse system behavior? +

Short answer: A larger load capacitance or bandwidth limit can “hide” the spike while stretching settling, causing larger error at the actual sampling moment.

Why: Filtering reduces peak amplitude but increases time constant; if the system samples before full settling, the residual error can grow even when the spike looks smaller.

Check:

• Sampling/loop timing relative to the step response and error band.
• Load and bandwidth changes between lab measurement and real system.
• Boundary-crossing steps under real load (not only small steps).

Fix:

• Prioritize settling-to-threshold at the system’s sampling time, not peak spike aesthetics.
• Validate with the real load and the real update/sampling timing.

Verify: Use identical bandwidth, load, and threshold definitions when comparing “glitch improvement” claims.

What causes code-dependent spurs in segmented DACs? +

Short answer: Repeated code sequences can modulate static element mismatch and boundary mapping into discrete tones (spurs) even when average linearity looks acceptable.

Why: Static errors become visible as spectral lines when the input sequence repeatedly visits the same error pattern with a fixed periodicity; boundary-adjacent activity can amplify this effect.

Check:

• Spur strength changes when the code ordering/periodicity changes at the same amplitude.
• Spur concentrates when boundary-adjacent codes are visited more frequently.
• Spur location relates to sequence periodicity and update timing.

Fix:

• Change code pattern first (same amplitude), then re-check spurs.
• Reduce repeated boundary crossing if a spur is boundary-sensitive.

Verify: Hold update rate, record length, windowing, and load constant when comparing spur behavior across patterns.

How to tell if a spur is pattern-bound or “clock/update-path” bound? +

Short answer: Change one lever at a time: code pattern first, then update rate/clock cleanliness, then load/driver; binding reveals the root cause category.

Why: Pattern-bound spurs track the sequence; update-path issues track timing/clock conditions; output-chain distortion tracks load/swing sensitivity.

Check:

• Same amplitude, different ordering/periodicity: spur moves/vanishes → pattern-bound.
• Same pattern, cleaner/rougher clock: floor/tones change strongly → update-path bound.
• Same pattern/clock, different load/swing: harmonics/IMD jump → chain-bound.

Fix:

• Pattern-bound: reduce repeated boundary activity or de-correlate sequences.
• Update-path bound: improve update timing integrity (without expanding protocol details here).
• Chain-bound: validate driver/load linearity sensitivity under the same measurement conditions.

Verify: Only one lever may change per experiment; otherwise attribution collapses.

What does “monotonic guarantee” really mean for a segmented DAC? +

Short answer: A datasheet monotonic claim is about static transfer behavior under stated conditions; system-level “effective monotonicity” can be broken by noise, drift, and load disturbances.

Why: Even if the ideal curve is monotonic, boundary sensitivity and external chain effects can create momentary reversals or non-repeatable steps at the measurement point.

Check:

• Does monotonicity apply over temperature and supply, or only typical at 25°C?
• Is the worst-case set (boundary/large steps) included in monotonic characterization?
• Is the measurement point after the output chain stable and repeatable?

Fix:

• Validate monotonicity at the system measurement node, not only at the DAC pin.
• Include boundary-adjacent codes and thermal corners in validation.

Verify: Effective monotonicity must be checked with the real load and the real settling time budget.

Why do INL/DNL and “output accuracy” drift with temperature in segmented DACs? +

Short answer: Temperature changes mismatch, gradients, and switching behavior, which reshapes INL/DNL and can amplify boundary sensitivity even when the reference is stable.

Why: Unit-element and weighted-element errors have temperature dependence; segmentation changes how those errors map into codes, so the boundary region may shift in dominance across temperature.

Check:

• INL shape repeatability across temperature cycling (shape stability matters).
• Boundary-zone behavior vs temperature (hot-zone migration).
• Warm-up vs ambient temperature effects (time vs temperature separation).

Fix:

• Characterize at controlled thermal points and log the time-from-power-up.
• Use boundary-focused screening at thermal corners, not just room temperature.

Verify: Compare INL/DNL only when thermal state (temperature + soak time) is controlled and documented.

Why are vendor glitch impulse numbers often not comparable? +

Short answer: Glitch impulse depends strongly on bandwidth, integration window, trigger method, load, output mode, and code pattern; changing any of these changes the number.

Why: Glitch is a transient phenomenon; measurement setup and definition determine how much energy is captured and how it is integrated.

Check:

• Bandwidth limit used for capture.
• Integration window length and placement relative to the update edge.
• Load and output mode (single-ended/differential) during test.
• Transition set (mid-scale vs boundary vs extremes).

Fix:

• Request the full condition fields with the glitch number.
• Re-measure with the system’s real load and update pattern when possible.

Verify: A comparison without matched conditions is not a comparison.

Which settling definition should be used: 0.5 LSB, 1 LSB, or ppm? +

Short answer: Use the threshold that matches the system error budget at the sampling instant; the stricter the threshold, the more the output chain dominates the result.

Why: Settling is a “time-to-enter-and-stay” statement relative to a band; changing the band changes what mechanism becomes limiting (core vs chain vs measurement noise).

Check:

• System sampling time (or control loop deadline) after update.
• Required residual error at that time (LSB/ppm derived from budget).
• Step size and whether the step crosses the segmentation boundary.

Fix:

• Specify settling with threshold + hold window + step size + load in requirements.
• Validate the worst-case set (boundary + large steps) against the same definition.

Verify: Settling comparisons require identical threshold, hold window, bandwidth, and load.

What is a minimal production-screen strategy for segmented DAC risks? +

Short answer: Screen what fails structurally: boundary-zone behavior, large-step settling, and a small dynamic spur check with locked conditions; sample-test the rest if shape repeatability is proven.

Why: Segmented DAC failures often cluster in hot zones (boundary and large transitions) and in condition-sensitive measurements; targeted screens catch the dominant risk efficiently.

Check:

• Boundary-adjacent code subset: DNL hot spot or step disturbance check.
• Large-step settling: same threshold/hold-window definition as the system.
• One short FFT spur check with a defined pattern and record length.
• Thermal corner sample: boundary subset re-check at temperature extremes.

Fix:

• Define the locked condition fields once and reuse them across lines and sites.
• Classify results as “must-test” vs “sample-test” based on repeatability.

Verify: If conditions drift across stations (bandwidth/window/load/pattern), yield signals become noise.