In short: A latch is level-sensitive and transparent while its enable is active, whereas a flip-flop is edge-triggered and samples its input only at the clock transition — which is exactly why synchronous design standardizes on flip-flops to make timing predictable.
Ask any junior engineer "what's the difference between a latch and a flip-flop?" and you'll usually hear "one is edge-triggered." True, but incomplete. The real distinction — level-sensitivity versus edge-sensitivity — ripples all the way through to how a static timing analysis (STA) tool like Synopsys PrimeTime or Cadence Tempus closes timing on your chip. Getting this wrong is how unintended latches sneak into RTL and how a design that simulates perfectly fails silicon. Let's build the intuition from the ground up.
Storage elements: both remember a bit, differently
Both devices store one bit. The difference is when they are allowed to change. A latch watches a control signal (an enable or gate) and, as long as that control is at its active level, the output follows the input — the latch is said to be transparent. When the control goes inactive, the latch holds (opaque). A flip-flop ignores the data except at one instant: the rising (or falling) edge of its clock. In between edges it is frozen, regardless of how the data wiggles.
A positive-level D latch is transparent while EN = 1. A positive-edge D flip-flop captures D only during the sub-nanosecond window around the 0→1 clock transition. That single difference drives everything below.
Internally: two latches make one flip-flop
A standard edge-triggered D flip-flop is literally built from two latches in a master-slave configuration, driven by complementary clocks. While the clock is low, the master latch is transparent and tracks D; the slave holds. On the rising edge the master goes opaque (capturing the last value of D) and the slave becomes transparent, passing that captured value to Q. Because the master closes the instant the slave opens, the input value is sampled at exactly one point — the edge. This is why a flip-flop costs roughly twice the transistors of a single latch (about 20–24 transistors versus ~10 for a latch in a typical standard-cell library).
Why timing cares: the transparency problem
Here is the crux. In STA, a flip-flop has clean, well-defined constraints: setup time (data must be stable before the edge), hold time (data must stay stable after the edge), and clock-to-Q propagation. Data launched by one flop must arrive and settle at the next flop before its capturing edge. One clock period, one launch, one capture — the arithmetic is simple.
A latch breaks that simplicity. Because it is transparent for half the clock cycle, data can flow through it during the transparent window. This enables a powerful technique called time borrowing (or cycle stealing): a slow combinational path can "borrow" slack from the next stage because the latch didn't gate the data at a fixed instant — it passed it through as soon as it arrived. Latch-based designs can be faster, but the timing model is far harder: the tool must reason about arrival times relative to the transparency window, not a single edge.
Latch vs flip-flop at a glance
| Property | D Latch | D Flip-Flop |
|---|---|---|
| Trigger | Level (enable high/low) | Edge (rising or falling) |
| Transparency | Transparent while enabled | Never transparent — snapshot only |
| Timing in STA | Time borrowing, two-phase checks | Single setup/hold per edge |
| Transistor count (typical) | ~8–12 | ~20–24 (master-slave) |
| Glitch sensitivity | Passes glitches while transparent | Immune between edges |
| Typical use | High-perf datapaths, pulsed-latch CPUs | Default synchronous registers |
The classic RTL trap: inferred latches
In Verilog/SystemVerilog, writing combinational logic in an always @* block with an incomplete if or case — one that doesn't assign the output on every path — makes the synthesizer (Synopsys Design Compiler, Cadence Genus) infer a latch to hold the unassigned value. This is almost always a bug: it creates a level-sensitive storage element where you wanted pure logic, introducing transparency and often an unconstrained timing path. Siemens Questa and every linter flag it with a warning like "inferred latch." The fix is to assign a default value to every output or use a complete case. If you genuinely want a register, write a clocked always_ff block instead. Many of these subtleties are unpacked further in our deep dive on the D flip-flop.
Rule of thumb for interviews: if a question involves "which is faster" or "time borrowing," the answer is the latch. If it involves "why do we build synchronous systems this way," the answer is the flip-flop's single, predictable sampling edge.
When engineers deliberately choose latches
High-performance CPU design does use latches on purpose. Several generations of x86 and server cores used pulsed latches or two-phase non-overlapping clock schemes to exploit time borrowing and shave a gate delay off critical paths — at the cost of enormously more complex timing closure and clock design. Unless you are chasing the last 5% of frequency on a custom datapath, flip-flops remain the safe default. For a broader look at how these elements chain into counters and pipelines, see our guide on synchronous sequential circuits. If you are building these flows for production silicon, teams like Avecas's physical-design services handle the latch-vs-flop timing trade-offs during RTL-to-GDS closure.
Want to go from "I can define a flip-flop" to "I can close timing on a real block"? Our hands-on digital design track walks through STA, inferred-latch debugging, and master-slave internals with lab exercises. Explore CourseTron courses →
Frequently asked questions
Is a flip-flop just two latches?
Essentially, yes. A standard edge-triggered D flip-flop is a master-slave pair of D latches driven by complementary clock phases, which is what converts level-sensitivity into edge-triggered behavior.
Why are inferred latches considered bugs?
Because they usually appear by accident when a combinational block doesn't assign an output on every control path. The result is an unintended level-sensitive memory with transparency, which complicates timing and can cause simulation-versus-silicon mismatches.
Can a design use both latches and flip-flops?
Absolutely. Most SoCs are flip-flop based for predictability, but performance-critical datapaths or specific IP blocks may use latches to exploit time borrowing. The STA tool must be configured to analyze both correctly.
Does a latch consume less power and area than a flip-flop?
Generally yes — a latch uses roughly half the transistors, so pulsed-latch schemes can save area and clock power. The savings come at the price of much harder timing and clock-distribution design.