1. Identify the single-input complementary-driver boundary
Dead-time is meaningful only after the relationship between the two drive commands has been identified. In TI's LM5106, a single PWM input controls complementary high-side and low-side driver operation. The device therefore participates in generating the handover between those outputs. This differs from a requirement in which the host provides two independently scheduled drive commands and expects the driver merely to pass them onward.
That distinction belongs near the start of a candidate comparison. If the released controller expects one complementary-control input, a proposal described only as a half-bridge driver leaves the command architecture unresolved. Conversely, independent control requirements should not be silently translated into the LM5106 arrangement. The power-stage category identifies an intended role, while the input architecture explains how switching requests reach the two driver functions.
Use the named example to ask where the application's non-overlap requirement is implemented. Is the intended handover generated within the selected driver, or established elsewhere in the control system? That question exposes an architectural change without selecting a resistor, reconstructing a diagram or prescribing a switching sequence. Two candidates can address similar power-stage roles while assigning this timing responsibility differently.
2. Separate programmed dead-time from signal transit
TI names turn-on and turn-off propagation delays separately from the interval between one output turning off and the other turning on. Propagation concerns the transit from a controlling event to an output response. Dead-time concerns the relationship between the two output events. These descriptions share timing terminology, but their start and end events differ, so one cannot stand in for the other.
This matters when a shortened comparison lists a driver simply as fast. A short signal-transit description does not identify the intended non-overlap interval. Likewise, a programmable dead-time feature does not provide every propagation characteristic needed by the controller. Keep the event pair attached to each timing description before deciding which evidence applies to the application's switching handover or its separate command-response requirement.
The LM5106 overview describes adjustment of dead-time through its programming function. That supports the existence and purpose of a controllable interval in this device. It does not establish an application setting or an acceptable interval for another driver. A useful comparison asks whether the documented adjustment function addresses the required handover, with numerical selection left to the applicable engineering evidence.
3. Keep enable and supply inhibition distinct
An enable function decides whether driver operation is permitted. Programmable dead-time instead shapes the transition between complementary outputs during the described operation. Confusing those roles can produce a requirement that asks for an adjustable handover but cites only a shutdown feature. The LM5106 includes enable alongside its single-input timing architecture; neither feature name should erase the other from the functional comparison.
Supply-undervoltage lockout introduces another condition. TI describes inhibition associated with the driver supplies, rather than a new user-selected handover interval. An output held inactive because its supply condition is insufficient is therefore a different event from an output awaiting its complementary switching transition. These mechanisms need separate descriptions even though both can appear as an inactive driver output in an informal account.
Consider a system that needs both an ordinary switching handover and a controlled permission to stop driving. The comparison must address both responsibilities, then retain the relevant supply-inhibition description separately. Seeing an inactive output would not by itself tell a reviewer which responsibility caused it. This is a functional distinction, not a truth-table recipe or a claim about the customer's startup behavior.
4. Review the required switching handover
Frame the final requirement around the handover the power stage actually needs. State the command architecture, the output-event relationship requiring non-overlap and the separate permission or supply conditions that can inhibit operation. These inputs let engineering identify the relevant timing evidence. They are more informative than combining every inactive interval under a single generic delay label in a sourcing request.
Keep the driver-level description separate from the complete power-stage outcome. A documented dead-time function describes how the driver manages its outputs under the specified context. It does not report the switching behavior of the customer's MOSFETs and assembled circuit. Calling the function shoot-through prevention without that qualification would turn a component feature into an application guarantee that this evidence does not supply.
The related MOSFET gate-drive question concerns a different device condition, while isolation concerns the endpoints of a barrier and stepper decay concerns winding-current control. None substitutes for complementary handover evidence. A focused request asks whether the exact driver's control and timing architecture fits the released handover requirement, leaving device settings and actual switching assessment as distinct engineering decisions.
Sources and further reading
TI LM5106 text on physical pages 6 and 11 was reread for timing terminology, single-input control, enable and UVLO roles. Figures were not interpreted. No delay or resistor values, connection recipe, whole-datasheet review or assembled switching result is supplied.