Deadtime & Shoot-Through Interlock for Gate Drivers

Q: After MCU reset, bridge momentarily overlaps—EN/FAULT priority wrong or pin default floats?

Likely cause: /EN is not dominant during reset, or IN pins float/tri-state causing unintended edges before the interlock policy is active. Quick check: capture /EN, IN_H/IN_L, OUT_H/OUT_L during reset; inspect the first X µs for any OUT activity. Fix: force /EN low through reset (hardware), add input pulls to define defaults, and set priority so /EN (and/or UVLO) always forces Both-OFF. Pass criteria: OUT stays S0 for ≥ X ms after reset; overlap events = 0 over Y reset cycles (N = 0 failures).

Q: Interlock present, yet overlap occurs—common cause: separate drivers / unsynchronized inputs?

Likely cause: HS and LS are driven by separate devices without a shared interlock, or complementary inputs are not updated synchronously (skew/phase slip). Quick check: verify HS/LS outputs originate from the same interlock block; measure channel skew between OUT_H and OUT_L. Fix: route both channels through a single hardware interlock (or use a dual driver with built-in mutual exclusion) and enforce synchronous input updates. Pass criteria: channel skew ≤ X ns; effective OUT deadtime ≥ DT_min + X ns margin across Y runs.

Q: Deadtime sweep shows “cliff” behavior—threshold jitter or blanking window interaction?

Likely cause: threshold chatter or quantized DT steps interact with blanking/filter windows, producing abrupt behavior at a boundary. Quick check: repeat sweep with smaller ΔDT = X ns and log DT_actual; check whether faults cluster at the same DT boundary. Fix: adjust deglitch/blanking window (X/Y ns), add hysteresis where available, and choose DT away from the boundary by ≥ X ns. Pass criteria: sweep results are monotonic within ±X%; boundary faults ≤ N / hour (target N = 0).

Q: Half-bridge OK, full-bridge shoot-through—cross-leg timing assumption broken?

Likely cause: leg-to-leg timing is not aligned; one leg’s DT or input timing violates the assumed update boundary in full-bridge operation. Quick check: capture all four OUT signals and compare DT and skew per leg; verify update occurs at the same PWM boundary. Fix: enforce identical DT settings and priority policy across legs; lock complementary updates to a single synchronized timing edge. Pass criteria: leg-to-leg DT mismatch ≤ X ns; overlap events = 0 at f_sw = X kHz over Y minutes.

Q: Isolated input causes sporadic overlap—common-mode transient → input edge ambiguity?

Likely cause: isolation-side transient creates ambiguous edges or short glitches at the driver-side input; channel skew reduces effective deadtime. Quick check: probe IN at the driver side during dv/dt stress; measure glitch width and channel-to-channel skew. Fix: apply input deglitch (≥ X ns), set min/max DT clamps, and require fault-dominant Both-OFF fallback on abnormal input behavior. Pass criteria: under dv/dt stress, unintended IN toggles = 0; overlap events = 0; faults ≤ N / hour.

Deadtime and hardware interlock exist to guarantee break-before-make at the gate outputs, preventing shoot-through even when PWM timing is imperfect. The engineering goal is to define one measurable deadtime metric, compute a minimum safe value with margins, then tune within an optimum window that meets spike, loss, EMI, and fault-response criteria (X/Y/N).

Definition: Deadtime & Shoot-Through Interlock

This section locks a single engineering vocabulary for deadtime, shoot-through, and hardware interlock—so timing budgets and pass/fail criteria remain consistent across design, bring-up, and audit.

Deadtime: the enforced break-before-make time window between high-side (HS) and low-side (LS) gate-drive commands within the same half-bridge.

Shoot-through: unintended cross-conduction in a half-bridge where HS and LS simultaneously provide a conductive path, creating a bus short and injecting energy into devices and layout parasitics.

Hardware interlock: driver-level mutual exclusion logic that blocks overlap even if PWM commands glitch, jitter, or momentarily contradict (including reset/boot states).

What the terms are (and are not)

Deadtime insertion is a scheduled gap introduced by PWM logic or the driver configuration.
Interlock is a safety mechanism that enforces mutual exclusion regardless of what the controller requests.
Shoot-through is the hazard outcome (current/energy), not the control feature.

Default engineering reference used on this page

Unless stated otherwise, “deadtime” refers to the driver output-level gap (OUT_H vs OUT_L / gate-drive outputs), because it captures controller timing, driver propagation mismatch, and output asymmetry in one measurable reference.

Owns: deadtime semantics Owns: interlock behavior Owns: budget & pass criteria

Scope boundary to prevent sibling overlap

Miller/dv/dt effects appear only as inputs that can extend effective overlap; mechanism details belong to Active Miller Clamp.
Propagation delay/skew definitions and deep test methodology belong to Propagation Delay & Matching.
Two-level edge shaping belongs to Two-Level Turn-On/Off.

Diagram 1 shows the control chain (PWM → deadtime insert → driver interlock → outputs) and a timing comparison: overlap without deadtime vs a forced deadtime gap with interlock enforcement.

Failure Model: Why Shoot-Through Happens in Real Hardware

Shoot-through is rarely caused by a simple “both commands high” condition. It is typically the result of effective overlap: one device still has conduction capability while the opposite device begins to turn on.

Effective overlap (the only definition that matches field failures)

Effective overlap window exists when HS has not fully lost its conductive path (tail current / incomplete gate discharge / output asymmetry) while LS has already gained conductive capability (gate threshold crossing plus driver strength). This can happen even when input PWM edges appear non-overlapping.

Three root-cause paths (each mapped to what can be measured)

Command path (controller intent): PWM jitter, narrow glitches, reset/boot ambiguity, floating enables.
Measure anchor: IN_H / IN_L logic-level capture (scope or logic analyzer).
Driver path (timing + asymmetry): tPLH/tPHL mismatch, channel skew, unequal source/sink currents, output stage tails.
Measure anchor: OUT_H / OUT_L edge placement and fall/rise tails.
Power device path (effective turn-off delay): slow discharge of Vgs, bounce-induced re-crossing, reference shift that extends conduction window.
Measure anchor: Vgs_H / Vgs_L plus Vsw and bus current proxy during transitions.

Energy view (engineering metric, not device physics)

Shoot-through severity is governed by energy injected during the overlap: E_shoot ≈ ∫ V_bus · I_shoot dt When full integration is not practical, a robust comparison proxy is Vbus × I_peak × Δt_overlap under identical test conditions (same load, temperature, bus voltage, and measurement reference).

Minimal fault-isolation order (fastest path to root cause)

Step 1: Confirm command correctness — check IN_H/IN_L for glitches, reset states, or unexpected simultaneous assertions.
Step 2: Confirm driver reality — measure OUT_H/OUT_L to expose propagation mismatch, skew, and output tail asymmetry.
Step 3: Confirm effective overlap — correlate Vgs and Vsw with a current proxy to validate overlap energy and timing.

Diagram 2 ties real failure causes to observables: mismatch and tails create an effective overlap window (Δt), producing an Ishoot spike (I_peak) and energy injection.

Deadtime Semantics & Measurement Definitions (No Ambiguity)

Deadtime must be defined by a measurement reference. Without a fixed reference, budgets, optimization results, and pass/fail reports become non-comparable and audit disputes are guaranteed.

Default reference on this page: Gate-output deadtime (OUT_H vs OUT_L). This reference aligns controller timing, isolation/logic delay, driver propagation mismatch, and output-stage asymmetry in one measurable point.

Three deadtime definitions (each tied to a measurement point)

1) Command Deadtime (PWM-inserted)

Definition: the gap between the controller’s HS command edge and LS command edge (IN_H vs IN_L).

Best for: validating PWM configuration, firmware logic, reset/boot behavior, and unexpected command overlap.

Can mislead when: driver/isolator delay mismatch or output-stage tails consume the commanded gap.

2) Gate-Output Deadtime (Driver-output gap)

Definition: the gap between OUT_H becoming effectively OFF and OUT_L becoming effectively ON (OUT_H vs OUT_L).

Best for: board-level acceptance, driver comparison, and timing-budget closure.

Can mislead when: external gate networks (buffers / discrete stages) separate OUT from the actual Vgs behavior.

3) Switch-Node Deadtime (Vsw-based)

Definition: the non-overlap window inferred from switch-node transition behavior (Vsw timing around commutation).

Best for: understanding diode/third-quadrant conduction windows and commutation losses.

Can mislead when: probe placement, parasitics, load-current polarity, or ringing shift the apparent transition timing.

Hard rule: a report must state the deadtime reference (Command / OUT / Vsw). Mixing references inside one conclusion invalidates comparisons.

Recommended measurement points (fastest dispute-proof workflow)

IN_H / IN_L: prove command correctness (glitch, reset ambiguity, unintended overlap).
OUT_H / OUT_L: prove driver reality (propagation mismatch, skew, rise/fall asymmetry, tails) — default acceptance reference.
Vgs_H / Vgs_L: confirm gate-level behavior (re-crossing, rebound, incomplete discharge) without expanding device physics.
Vsw: correlate commutation timing with energy/loss observations; treat as context, not the only acceptance metric.

Owns: measurement semantics Owns: acceptance reference No deep: prop-delay test method

Deep propagation-delay test standards belong to Propagation Delay & Matching. This section only defines how deadtime is named, located, and compared.

Diagram 3 aligns the same switching event across IN, OUT, Vgs, and Vsw. Each deadtime definition is measured on a different lane; gate-output deadtime is the default acceptance reference.

Hardware Interlock Architectures (Break-Before-Make in Silicon)

A robust interlock is not only “mutual exclusion.” It is a combination of mutual exclusion, priority override, glitch handling, and minimum-off-time enforcement—so overlap is blocked even during noise, resets, or contradictory commands.

Interlock building blocks (the audit-friendly model)

Mutual exclusion: OUT_H and OUT_L cannot be ON at the same time.
Priority override: UVLO / FAULT / DISABLE forces safe outputs regardless of IN_H/IN_L.
Glitch handling: short pulses and edge races are filtered or blanked.
Minimum off-time: break-before-make is guaranteed as a physical minimum, not a best-effort gap.

Common architectures (what each solves, what each can miss)

1) Simple AND Gating (mutual gate)

Idea: allow one side only when the opposite side is not asserted.

Strength: low added latency, simple behavior.

Risk: vulnerable to input edge races and narrow glitches unless additional filtering is present.

2) Cross-Coupled Latch (race-resistant)

Idea: lock the allowed side, preventing momentary overlap during competing edges.

Strength: strong suppression of edge races and ambiguous transitions.

Risk: reset default and override priorities must be explicit; otherwise boot states may be unpredictable.

3) Blanking Window (glitch & bounce suppression)

Idea: after a transition, ignore opposite-side events inside a short time window.

Strength: swallows short glitches and bounce-like edges.

Risk: too short → ineffective; too long → can suppress legitimate PWM pulses.

4) Fault-Dominant Gating (safe-state enforcement)

Idea: FAULT/UVLO/DISABLE overrides the command path and forces outputs OFF (or latched-OFF).

Strength: clear safety behavior for audits and production tests.

Risk: latch vs auto-retry policy must be defined; otherwise field behavior appears inconsistent.

Priority rules (what must override what)

Recommended priority order: UVLO / FAULT / DISABLE (highest) → Interlock mutual exclusion → IN_H / IN_L (lowest).

Reset default: outputs must enter both-off as the safe state until enables and inputs are valid.

Key parameters that affect deadtime and safety

Interlock propagation: interlock logic delay that can consume commanded deadtime or add extra delay.
Minimum off-time: guaranteed break-before-make floor independent of command waveform.
Input glitch filter time: minimum pulse width that can pass; defines glitch immunity vs pulse swallowing risk.

Design review checks: reset safe state is both-off; glitch handling blocks narrow pulses; fault/uvlo overrides outputs within a defined response-time window (X/Y).

Diagram 4 shows an audit-friendly interlock model: IN_H/IN_L feed mutual exclusion (latch + blanking), while UVLO/FAULT/DISABLE override the command path and force safe outputs.

Programmable Deadtime: Methods, Resolution, Drift

Programmable deadtime must be evaluated as an engineering control loop: where it is inserted, what resolution it provides, and how it drifts across temperature, supply, and process. The goal is repeatable acceptance at the default reference (gate-output deadtime).

Implementation paths (where deadtime is inserted)

1) Controller / PWM Timer Insertion (digital)

Inserted at: command layer (IN_H / IN_L).

Strength: easy sweep and system-level coordination (phase, complementary outputs).

Risk: does not automatically guarantee the gate-output gap; driver/isolator delay mismatch can consume the commanded gap.

2) Driver IC Insertion (register / pin / OTP)

Inserted at: driver logic (near OUT_H / OUT_L).

Strength: strongest alignment to board-level acceptance; improves repeatability across builds.

Risk: internal blanking/min-off-time can interact with external PWM; budget must include interlock propagation and clamps.

3) RC / Analog Delay (low-cost)

Inserted at: analog threshold/RC time constant stage.

Strength: minimal BOM and simple circuits in tolerant systems.

Risk: large drift with PVT; noise/threshold sensitivity reduces traceability for acceptance reports.

Resolution and error sources (what limits “how fine”)

Clock quantization: timer ticks or internal step size sets the minimum increment.
Input jitter / edge variability: command-side jitter can translate into deadtime uncertainty at OUT.
Temperature coefficient: delay elements and output stages shift across temperature corners.
Process spread: silicon delay dispersion and RC tolerance widen the distribution across units.
Supply variation: driver strength and internal delay shift with VDD and bias headroom.

Acceptance items required for “programmable” claims

Step size: minimum increment = X ns (or X ticks), measured at OUT_H/OUT_L.

Monotonicity: increasing setting must not produce a smaller measured gate-output deadtime (allow ±X ns measurement tolerance).

Temperature coefficient: drift over T_low…T_high ≤ X ns or X% at fixed setting.

Min/Max clamp: out-of-range settings must clamp to defined limits with deterministic behavior.

Pick insertion point Verify step + monotonic Characterize drift (PVT)

Deep propagation-delay measurement methods are not expanded here; only the impact on programmable deadtime is captured. Reference: Propagation Delay & Matching.

Diagram 5 compares three insertion locations. Driver-level insertion typically provides the best repeatability at the gate-output deadtime reference, while RC delay is the most drift-sensitive across PVT.

Timing Budget: How to Compute Minimum Safe Deadtime

Minimum safe deadtime must be computed as a worst-case timing budget. The objective is to prevent effective overlap across PVT corners and measurement uncertainty, using the default acceptance reference: gate-output deadtime.

DT_min is the minimum gate-output deadtime that guarantees no effective overlap at the driver outputs under worst-case conditions. Compute both directions (HS→LS and LS→HS) and apply the larger requirement.

Budget terms (what consumes the available gap)

Driver propagation mismatch (ΔtPD): channel delay differences shrink or invert the intended gap. (Definition referenced from the Timing page.)
Output rise/fall asymmetry + tail-off: unequal source/sink behavior extends effective conduction on the turning-off side.
Gate-loop parasitics (delay/bounce): loop inductance and reference shift can cause delayed discharge or re-crossing at the gate.
Temperature drift + supply variation: delay and drive strength shift across T/V corners.
Measurement uncertainty margin: probe bandwidth, threshold definition, and trigger placement add uncertainty.

Formula templates (audit-friendly and direction-aware)

Direction-aware worst-case templates

HS→LS: DT_min_HL ≥ |ΔtPD_HL| + t_tail_off_H + t_asym_L_on + t_parasitic + t_drift + t_meas + margin

LS→HS: DT_min_LH ≥ |ΔtPD_LH| + t_tail_off_L + t_asym_H_on + t_parasitic + t_drift + t_meas + margin

Final requirement: DT_min ≥ max(DT_min_HL, DT_min_LH)

Propagation-delay test methodology is not expanded here; only the budget usage is defined. Reference: Propagation Delay & Matching.

Budget-closure workflow (repeatable and reportable)

Fix the reference: gate-output deadtime at OUT_H/OUT_L with a consistent threshold definition (X% or fixed level).
Measure ΔtPD and skew: quantify channel mismatch and direction dependence at OUT.
Measure tail and asymmetry: capture effective OFF tail and ON threshold crossing timing at OUT and confirm with Vgs.
Add PVT drift: repeat at temperature and supply corners or apply validated drift bounds.
Add uncertainty + margin: include measurement uncertainty and a conservative margin (X ns or X%) before declaring DT_min.

Diagram 6 visualizes budget closure: delay mismatch, tails, asymmetry, parasitics, drift, and measurement uncertainty sum to DT_min, with an explicit safety margin highlighted.

Tradeoff: Too Little vs Too Much Deadtime (Loss, EMI, Reliability)

Deadtime is a multi-objective tradeoff. Too little increases shoot-through risk and protection stress; too much increases diode/third-quadrant conduction and recovery-related noise. The target is an acceptance window that passes safety gates and meets performance gates across operating corners.

Too little deadtime (what breaks first)

Risk & observable proxies

Shoot-through risk: current spike proxy rises (Ibus/Iphase peak, DC-link bump, spike count).
Thermal stress: temperature rise increases (ΔT at phase-leg, hotspot repeatability).
Protection chatter: fault counts climb (DESAT/OC/UVLO events, retry storms).
Short-circuit energy sensitivity: fault windows tighten and safe turn-off margin reduces (event envelope grows).

Too much deadtime (where loss and EMI degrade)

Loss chain & observable proxies

Diode / reverse conduction time increases: conduction loss grows, especially at high current.
Recovery-related spikes increase: current transients and Vsw noise can worsen.
Efficiency drops: η declines at fixed output power; thermal margin shrinks.
Ringing signature shifts: Vsw ringing and spectral content can increase in certain corners.

Optimization workflow (sweep → observe → pick a window)

Step 1 (reference): use gate-output deadtime (OUT_H/OUT_L) as the acceptance reference.

Step 2 (range): start from DT_min (budgeted) and sweep upward in fixed increments (ΔDT = X ns).

Step 3 (observe): collect Ishoot proxy, Vsw ringing, efficiency (η), and temperature rise (ΔT).

Step 4 (gates): mark boundaries where safety or performance criteria fail; choose the stable region between them.

Pass criteria placeholders (turn observations into acceptance)

ΔT gate: ΔT ≤ X °C at Y minutes steady state (same ambient and load).
η gate: η ≥ X% (or ≥ baseline − X%).
Ispike gate: Ishoot proxy ≤ X A_peak (or ≤ X% over baseline), spike count ≤ Y / minute.
Fault gate: fault count ≤ X / hour; no latch events in Z cycles.

DT too small: risk ↑ DT too large: loss ↑ Target: optimum window

Diagram 7 illustrates the U-shaped tradeoff. The target is an optimum window where shoot-through risk is controlled while diode-related loss and noise remain acceptable.

Adaptive Deadtime & Auto-Tuning (When and How to Trust It)

Adaptive deadtime should be reviewed as a safety-bounded control loop. It can track the optimum window drift across temperature, device spread, and load changes, but it must be constrained by clamps, rate limits, and fail-safe fallback. Hardware interlock remains the hard guarantee of mutual exclusion.

What adaptive deadtime senses (engineering inputs, not theory)

Vsw signature / zero-cross: detects commutation timing cues and conduction windows.
Diode conduction detection: infers whether diode/third-quadrant conduction dominates.
Current polarity: decides which direction needs more conservative spacing.
Blanking window: ignores switching-edge noise to avoid false triggers.

What it fixes (why it exists)

Optimum-point drift sources

Temperature drift: delays and thresholds shift across corners.
Device and board spread: batch-to-batch variations move the best window.
Load variation: current direction and magnitude change the loss-risk balance.

Where it can fail (conditions that trigger mistrust)

Risk hotspots

Light-load / near-zero current: detection becomes ambiguous; updates can chatter.
Noise-coupled sensing: Vsw/I signals can be polluted; false updates occur.
Boundary switching (polarity flips): sign changes can cause rapid toggling.

Mandatory guardrails (non-negotiable constraints)

Min clamp: DT ≥ DT_min (budgeted minimum safe deadtime).

Max clamp: DT ≤ DT_max (defined by loss/temperature gates).

Rate limit: ΔDT per update ≤ X ns; update rate ≤ Y Hz.

Fault fallback: detection invalid → freeze updates and revert to DT_safe.

Interlock independence: hardware interlock must enforce mutual exclusion regardless of DT updates.

Trust checklist (validation outcomes)

Convergence: reaches a stable DT within X seconds from initialization.
Stability: steady-state DT jitter ≤ X ns (or ≤ X steps).
Robustness: no clamp violations during noise injection, light-load, and polarity transitions.
Fail-safe: invalid sensing forces DT_safe and records a traceable event.

Diagram 8 frames adaptive deadtime as a bounded loop: sense → detect → update DT → PWM, constrained by min/max clamps, rate limits, and fault fallback, while hardware interlock remains an independent hard safety guarantee.

Interlock Behavior During Faults & Transients (The Truth Table You Test)

Interlock behavior must be auditable. During faults and transients, OUT_H/OUT_L must enter a defined safe state with a defined maximum response time. This section defines the acceptance truth table as event → expected output state → response-time limit.

Safe output states (observable at OUT pins)

State definitions

S0 — Both OFF: OUT_H = OFF and OUT_L = OFF.
S1 — Fault-dominant OFF: regardless of IN_H/IN_L, interlock forces S0 until release conditions apply.
S2 — Latched OFF: enter S0 and remain latched until reset/enable action releases it.
S3 — Auto-retry OFF: enter S0, wait T_retry, then allow controlled return while keeping mutual exclusion enforced.

Priority rules (what wins when multiple events occur)

Recommended priority: UVLO / supply invalid > /EN low > /FLT asserted > IN_H/IN_L.

Rule: a higher-priority condition must force OUT into the required safe state even if lower-priority inputs toggle.

Acceptance truth table (event → expected OUT → max response)

Testable entries (placeholders)

Event: /EN asserted low

Expected OUT state: S1 (Fault-dominant OFF) or S0

Max response time: t_resp_EN ≤ X ns/µs

Release: /EN high with valid supply and no fault (policy-defined)

Event: UVLO asserted (supply drops below threshold)

Expected OUT state: S1 → S0 (Both OFF)

Max response time: t_resp_UVLO ≤ X ns/µs

Release: supply recovers above UVLO release + internal ready (policy-defined)

Event: /FLT asserted

Expected OUT state: S2 (Latched OFF) or S3 (Auto-retry OFF)

Max response time: t_resp_FLT ≤ X ns/µs

Release: fault clear + reset/auto-retry timing (policy-defined)

Event: IN_H/IN_L glitch or minimum-pulse violation

Expected OUT state: remain in Normal with mutual exclusion preserved (no unintended toggles)

Max response time: glitch filter window = X ns (placeholder)

Release: not applicable (must be absorbed by filter/blanking)

Event: controller reboot / reset (IN state uncertain)

Expected OUT state: S0 (Both OFF) until valid input handshake (policy-defined)

Max response time: t_resp_RST ≤ X ns/µs

Release: explicit enable + valid complementary inputs

Minimal test workflow (inject → observe → pass)

Inject: toggle /EN, force UVLO, assert /FLT, inject IN glitches, trigger controller reset.
Observe: /EN, UVLO, /FLT, IN_H/IN_L, OUT_H/OUT_L (optional: Vgs for correlation only).
Pass: expected safe state reached and held; response time ≤ X; release behavior matches policy.

Define safe states Publish truth table Test response time

Diagram 9 shows the testable interlock behavior. Fault-dominant OFF forces both outputs OFF, then enters retry or latched behavior depending on policy, and returns only under explicit release conditions.

Implementation Hooks: Inputs, Isolation, and Noise Immunity (Only What Matters for Interlock)

Interlock reliability depends on input integrity. Noise-coupled inputs, isolation output glitches, and reference return issues can generate false pulses that challenge mutual exclusion. This section focuses only on what directly affects interlock correctness and test outcomes.

Input types (how they influence false triggering)

Single-ended vs differential

Single-ended: common-mode noise and ground bounce can move the apparent threshold and create short glitches.
Differential: improved common-mode immunity reduces false toggles, but pair symmetry is still required.

Isolation output integrity (glitch and skew)

Only interlock-relevant outcomes

Glitch risk: isolation-side transient spikes can become IN pulses that must be filtered.
Skew risk: channel mismatch can consume effective deadtime and shift acceptance margins.

Recommended hooks (minimum actions that matter)

Input deglitch / minimum pulse width: reject pulses shorter than X ns.

Blanking window: ignore input toggles inside a defined noise window near switching edges.

Symmetric routing: keep IN_H/IN_L paths symmetric and keep reference return continuous.

Threshold hygiene: use hysteresis where available to avoid threshold chatter.

Minimal validation (prove immunity without expanding into other pages)

Glitch injection: inject an X ns pulse on IN and confirm OUT does not toggle unexpectedly.
Noise condition test: under switching dv/dt noise, verify clamp/blanking absorbs spurious input events.
Acceptance: no clamp violations; deadtime does not exceed allowed jitter; fault logs are traceable.

Glitch → filter Skew → margin loss Return integrity

Diagram 10 connects noise to interlock outcomes: noise and return issues create threshold jitter and glitches; a deglitch/blanking stage must absorb them to prevent unintended OUT toggles.

Engineering Checklist (Design → Bring-Up → Production)

This checklist turns deadtime and shoot-through interlock into an executable SOP. Each gate defines mandatory actions, required deliverables, and pass criteria placeholders (X/Y/N) to prevent ambiguity during reviews, debug, and production acceptance.

Design Gate (design review)

Do

Freeze deadtime measurement semantics: define IN / OUT / Vgs / Vsw alignment; set the default acceptance metric as Gate-output deadtime (OUT_H/OUT_L gap).
Budget DT_min: include |ΔtPD|, turn-off tail, drift, supply variation, measurement uncertainty, and margin (no wide tables).
Confirm interlock priority: define precedence for UVLO, /EN, /FLT, and IN_H/IN_L so that higher-priority events always force a safe state.
Design for testability: ensure OUT_H/OUT_L and /EN/UVLO/FLT injection points are observable and accessible without breaking safety.

Deliverables

Deadtime definition page: measurement points + threshold rule + acceptance metric.
DT_min budget list: stacked terms with X placeholders for each margin element.
Interlock truth table draft: event → expected OUT state → max response time (X ns/µs).
Bring-up sweep plan: DT range, step size, logging fields, and stop conditions.

Pass criteria (placeholders): DT_min_budgeted = X ns; priority is unambiguous; required test points exist; truth table is reviewable and testable.

Reference parts (MPN examples)

Isolated/dual gate driver (timing baseline): TI UCC21520 (or UCC21520-Q1).
Reinforced isolated driver w/ complementary inputs / split outputs: TI ISO5852S (or ISO5852S-Q1).
Isolated single-channel driver (Miller clamp option): ADI ADuM4135.
Isolated driver family (dual-channel variants): Silicon Labs/Skyworks Si823x / Si8233 family.
Input threshold noise hardening (Schmitt): TI SN74LVC1G14.
Minimum pulse width / deglitch window (monostable): TI SN74LVC1G123.

Define Budget Prioritize Testable

Bring-Up Gate (power-up debug)

Do

Deadtime sweep: sweep DT from DT_min toward DT_max using step size ΔDT = X ns; log each point consistently.
Log shoot-through proxies: record current spike proxy (I_spike), temperature rise (ΔT), efficiency (η), and fault count (N_fault).
Inject faults and transients: /EN low, UVLO dip, /FLT assert, IN glitch pulses, and controller reset to verify the truth table behavior.
Validate noise immunity minimally: confirm deglitch/blanking absorbs short pulses without unintended OUT toggles.

Deliverables

Sweep log: DT → {I_spike proxy, ΔT, η, N_fault} with screenshots or numeric captures.
Optimum window summary: selected DT window + margin rationale (why this window is trusted).
Truth table test record: per-event OUT state + measured response time t_resp (X ns/µs).
Anomaly list: failures, root cause tags (glitch/skew/UVLO), and corrective actions.

Pass criteria (placeholders): I_spike ≤ X; ΔT ≤ X°C; η ≥ X%; N_fault ≤ Y per hour; t_resp_EN/UVLO/FLT ≤ X ns/µs; no evidence of overlap events during injections.

Reference parts (MPN examples)

Current spike proxy (shunt amplifier): TI INA240 (or INA240-Q1) for PWM-friendly current sensing.
Controlled reset / reboot injection (supervisor): TI TPS3808 for repeatable reset behavior during validation.
Input cleanup for glitch stress tests: TI SN74LVC1G14 as a hysteresis front-end reference.
Glitch pulse shaping / minimum width reference: TI SN74LVC1G123 for programmable pulse windows.

Sweep Inject Log Window

Production Gate (manufacturing acceptance)

Do

Sample inspection: verify Gate-output deadtime (DT), channel skew, and fault response times on a sampling plan (N units per lot).
Response-time acceptance: test /EN, UVLO, and /FLT forcing; verify the expected safe state and t_resp within limits.
Configuration lock: record register/OTP/firmware versions that affect deadtime or interlock behavior.
Golden reference: maintain a golden unit waveform baseline for DT and response-time comparisons.

Deliverables

Production SOP: steps, measurement points, thresholds, and failure disposition.
Pass criteria sheet: DT = DT_target ± X; skew ≤ X; t_resp ≤ X; unexpected OUT toggles = 0.
Traceability record: lot → config version → test captures → disposition.

Pass criteria (placeholders): DT within ±X ns; skew ≤ X ns; t_resp_EN/UVLO/FLT ≤ X ns/µs; N failures ≤ Y per lot; configuration version matches release tag.

Reference parts (MPN examples)

Driver under test examples (for standardized acceptance): TI UCC21520, TI ISO5852S, ADI ADuM4135, SiLabs/Skyworks Si823x family.
Reset/reboot repeatability (line test helper): TI TPS3808 for deterministic reset assertion in fixture scenarios.
Input noise tolerance reference: TI SN74LVC1G14 as a baseline hysteresis device for stress variants.

Sample Time Lock Trace

Diagram 11 shows the 3-gate SOP. Each gate enforces the same discipline: measure, inject faults, log evidence, and lock pass criteria.

FAQs (Deadtime & Shoot-Through Interlock)

Scope: on-bench troubleshooting and acceptance disputes only. Each answer is fixed to four lines: Likely cause / Quick check / Fix / Pass criteria (X/Y/N).

+− Lab A passes, Lab B fails—deadtime measurement definition mismatch?

Likely cause: command vs gate-output vs switch-node deadtime is being mixed; thresholds/bandwidth/probe skew differ.

Quick check: capture IN_H/IN_L, OUT_H/OUT_L, Vgs_H/Vgs_L, Vsw with the same threshold rule and bandwidth.

Fix: standardize acceptance to gate-output deadtime (OUT gap), publish threshold and capture settings, and apply probe-skew correction.

Pass criteria: DT = DT_target ± X ns over Y repeats; inter-lab delta ≤ X ns (same setup).

+− DT set to X ns, but still see shoot-through spikes—first suspect mismatch or measurement point?

Likely cause: effective deadtime at OUT is smaller than assumed due to ΔtPD mismatch or turn-off tail; DT is being read at the wrong node.

Quick check: measure OUT_H/OUT_L gap at the defined threshold and correlate with Vsw + Ibus/shunt spike timing (same capture).

Fix: increase DT by X ns (or add margin X%) until the OUT gap clears ΔtPD + tail; keep interlock mutual exclusion enforced.

Pass criteria: I_spike ≤ Y A (or ≤ Y% of load) and fault count ≤ N / 10 min at f_sw = X kHz.

+− Scope shows no overlap at Vgs, but current spike exists—where else to confirm (Vsw/Ibus)?

Likely cause: overlap evidence is missing at the chosen probe point; current spike aligns with Vsw commutation, not with the probed Vgs timing.

Quick check: add Vsw and Ibus/shunt to the same timebase; check whether the spike occurs inside the computed OUT deadtime window.

Fix: re-validate deadtime at OUT (not only Vgs), then retune DT within the safe window while keeping the interlock state policy unchanged.

Pass criteria: I_spike ≤ Y A and ΔT ≤ X °C after Y minutes; no fault events (N = 0) in the same run.

+− Works at room temp, fails hot—deadtime drift or gate fall-time tail increased?

Likely cause: temperature drift increases ΔtPD or turn-off tail so DT_min is no longer met at hot; measurement uncertainty is under-budgeted.

Quick check: compare OUT deadtime (same threshold) and fault counts at room vs hot; log DT_actual vs DT_programmed.

Fix: increase DT margin by X% (or X ns), and enforce a minimum deadtime clamp across temperature corners.

Pass criteria: across T = (X_low…X_high) °C, I_spike ≤ Y A and faults ≤ N / hour with DT within ±X ns.

+− Random faults on fast PWM edges—input glitch filter too short or too long?

Likely cause: deglitch/blanking window does not match the real edge-noise envelope, causing false input pulses or missed valid transitions.

Quick check: inject controlled pulses (width = X ns…Y ns) at IN and verify which widths toggle OUT; correlate faults to edge timestamps.

Fix: set minimum pulse width ≥ X ns and blanking window = Y ns (placeholders), then re-run truth-table injections.

Pass criteria: pulses < X ns do not change OUT; faults ≤ N / hour at f_sw = X kHz.

+− After MCU reset, bridge momentarily overlaps—EN/FAULT priority wrong or pin default floats?

Likely cause: /EN is not dominant during reset, or IN pins float/tri-state causing unintended edges before the interlock policy is active.

Quick check: capture /EN, IN_H/IN_L, OUT_H/OUT_L during reset; inspect the first X µs for any OUT activity.

Fix: force /EN low through reset (hardware), add input pulls to define defaults, and set priority so /EN (and/or UVLO) always forces Both-OFF.

Pass criteria: OUT stays S0 for ≥ X ms after reset; overlap events = 0 over Y reset cycles (N = 0 failures).

+− Interlock present, yet overlap occurs—common cause: separate drivers / unsynchronized inputs?

Likely cause: HS and LS are driven by separate devices without a shared interlock, or complementary inputs are not updated synchronously (skew/phase slip).

Quick check: verify HS/LS outputs originate from the same interlock block; measure channel skew between OUT_H and OUT_L.

Fix: route both channels through a single hardware interlock (or use a dual driver with built-in mutual exclusion) and enforce synchronous input updates.

Pass criteria: channel skew ≤ X ns; effective OUT deadtime ≥ DT_min + X ns margin across Y runs.

+− Deadtime sweep shows “cliff” behavior—threshold jitter or blanking window interaction?

Likely cause: threshold chatter or quantized DT steps interact with blanking/filter windows, producing abrupt behavior at a boundary.

Quick check: repeat sweep with smaller ΔDT = X ns and log DT_actual; check whether faults cluster at the same DT boundary.

Fix: adjust deglitch/blanking window (X/Y ns), add hysteresis where available, and choose DT away from the boundary by ≥ X ns.

Pass criteria: sweep results are monotonic within ±X%; boundary faults ≤ N / hour (target N = 0).

+− Half-bridge OK, full-bridge shoot-through—cross-leg timing assumption broken?

Likely cause: leg-to-leg timing is not aligned; one leg’s DT or input timing violates the assumed update boundary in full-bridge operation.

Quick check: capture all four OUT signals and compare DT and skew per leg; verify update occurs at the same PWM boundary.

Fix: enforce identical DT settings and priority policy across legs; lock complementary updates to a single synchronized timing edge.

Pass criteria: leg-to-leg DT mismatch ≤ X ns; overlap events = 0 at f_sw = X kHz over Y minutes.

+− Isolated input causes sporadic overlap—common-mode transient → input edge ambiguity?

Likely cause: isolation-side transient creates ambiguous edges or short glitches at the driver-side input; channel skew reduces effective deadtime.

Quick check: probe IN at the driver side during dv/dt stress; measure glitch width and channel-to-channel skew.

Fix: apply input deglitch (≥ X ns), set min/max DT clamps, and require fault-dominant Both-OFF fallback on abnormal input behavior.

Pass criteria: under dv/dt stress, unintended IN toggles = 0; overlap events = 0; faults ≤ N / hour.

+− No shoot-through, but efficiency is low—deadtime too large or SR reverse conduction mis-timed?

Likely cause: deadtime is overly conservative, increasing diode/ reverse-conduction interval and switching loss without reducing shoot-through further.

Quick check: sweep DT downward from current setting by steps of X ns while monitoring I_spike proxy, ΔT, and η in the same operating point.

Fix: move DT toward DT_min + margin (optimum window) and clamp DT_max; keep interlock mutual exclusion unchanged.

Pass criteria: η improves by ≥ X% while I_spike ≤ Y A and faults ≤ N / hour; ΔT ≤ X °C.

+− DT increased reduces spikes but EMI worsens—diode recovery window moved?

Likely cause: larger DT shifts conduction into a less favorable commutation window, increasing Vsw ringing and emissions even if shoot-through spikes drop.

Quick check: compare EMI margin and Vsw ringing across two DT points (current and DT_min+margin) with identical measurement settings.

Fix: reduce DT toward the optimum window while maintaining I_spike limit; enforce DT_max clamp to avoid excessive diode interval.

Pass criteria: EMI margin ≥ X dB/µV and I_spike ≤ Y A; DT stays within [DT_min+X, DT_max] ns.

Acceptance tip: keep one canonical deadtime definition (gate-output deadtime at OUT thresholds) and log the same measurement settings whenever results are compared across benches, labs, or lots.

Deadtime & Shoot-Through Interlock in Gate Driver ICs

Deadtime & Shoot-Through Interlock in Gate Driver ICs

Definition: Deadtime & Shoot-Through Interlock

What the terms are (and are not)

Default engineering reference used on this page

Scope boundary to prevent sibling overlap

Failure Model: Why Shoot-Through Happens in Real Hardware

Effective overlap (the only definition that matches field failures)

Three root-cause paths (each mapped to what can be measured)

Energy view (engineering metric, not device physics)

Minimal fault-isolation order (fastest path to root cause)

Deadtime Semantics & Measurement Definitions (No Ambiguity)

Three deadtime definitions (each tied to a measurement point)

1) Command Deadtime (PWM-inserted)

2) Gate-Output Deadtime (Driver-output gap)

3) Switch-Node Deadtime (Vsw-based)

Recommended measurement points (fastest dispute-proof workflow)

Hardware Interlock Architectures (Break-Before-Make in Silicon)

Interlock building blocks (the audit-friendly model)

Common architectures (what each solves, what each can miss)

1) Simple AND Gating (mutual gate)

2) Cross-Coupled Latch (race-resistant)

3) Blanking Window (glitch & bounce suppression)

4) Fault-Dominant Gating (safe-state enforcement)

Priority rules (what must override what)

Key parameters that affect deadtime and safety

Programmable Deadtime: Methods, Resolution, Drift

Implementation paths (where deadtime is inserted)

1) Controller / PWM Timer Insertion (digital)

2) Driver IC Insertion (register / pin / OTP)

3) RC / Analog Delay (low-cost)

Resolution and error sources (what limits “how fine”)

Acceptance items required for “programmable” claims

Timing Budget: How to Compute Minimum Safe Deadtime

Budget terms (what consumes the available gap)

Formula templates (audit-friendly and direction-aware)

Direction-aware worst-case templates

Budget-closure workflow (repeatable and reportable)

Tradeoff: Too Little vs Too Much Deadtime (Loss, EMI, Reliability)

Too little deadtime (what breaks first)

Risk & observable proxies

Too much deadtime (where loss and EMI degrade)

Loss chain & observable proxies

Optimization workflow (sweep → observe → pick a window)

Pass criteria placeholders (turn observations into acceptance)

Adaptive Deadtime & Auto-Tuning (When and How to Trust It)

What adaptive deadtime senses (engineering inputs, not theory)

What it fixes (why it exists)

Optimum-point drift sources

Where it can fail (conditions that trigger mistrust)

Risk hotspots

Mandatory guardrails (non-negotiable constraints)

Trust checklist (validation outcomes)

Interlock Behavior During Faults & Transients (The Truth Table You Test)

Safe output states (observable at OUT pins)

State definitions

Priority rules (what wins when multiple events occur)

Acceptance truth table (event → expected OUT → max response)

Testable entries (placeholders)

Minimal test workflow (inject → observe → pass)

Implementation Hooks: Inputs, Isolation, and Noise Immunity (Only What Matters for Interlock)

Input types (how they influence false triggering)

Single-ended vs differential

Isolation output integrity (glitch and skew)

Only interlock-relevant outcomes

Recommended hooks (minimum actions that matter)

Minimal validation (prove immunity without expanding into other pages)

Engineering Checklist (Design → Bring-Up → Production)

Design Gate (design review)

Do

Deliverables

Reference parts (MPN examples)

Bring-Up Gate (power-up debug)

Do

Deliverables

Reference parts (MPN examples)

Production Gate (manufacturing acceptance)

Do

Deliverables

Reference parts (MPN examples)