In the highly regulated world of RTL (Register Transfer Level) design, one warning from the synthesis tool stands above all others as a harbinger of doom: "LATCH INFERRED." To a junior engineer, it looks like a simple hardware mapping. To a lead verification engineer, it is a catastrophic failure in coding discipline that could lead to non-deterministic silicon behavior.
The Core Definition
The difference lies in the trigger. A Flip-Flop is edge-triggered, sampling data only at the nanosecond transition of a clock. A Latch is level-sensitive, remaining "transparent" for as long as the clock is held at a specific level.
1. The Danger of Unintentional Inference
The primary reason latches are "dangerous" is that they are rarely invited into a design. In Hardware Description Languages like SystemVerilog, a latch is created whenever you write combinational logic but fail to specify an outcome for every possible input combination.
always_comb begin
if (enable) out = data;
// Missing 'else' branch!
end
Because the hardware must "remember" the previous state of out when enable is low, yet no clock edge was defined, the synthesis tool inserts a level-sensitive latch. In a complex chip with 100 million gates, an accidental latch can cause intermittent bugs that are impossible to replicate in functional simulation but fail in the physical world due to timing variations.
2. Glitch Propagation & Transparency
Unlike Flip-Flops, which act as barriers to logic noise, latches are transparent windows. While the clock is High, any "glitch" or momentary fluctuation in the combinational logic feeding the latch travels straight through to the output.
In an edge-triggered system, glitches usually settle long before the next clock edge. In a latch-based system, a glitch occurring during the transparency window can be sampled by the next stage, leading to corrupted data states. This makes timing closure—the process of ensuring every signal arrives on time—a mathematical nightmare.
The STA Nightmare
Static Timing Analysis (STA) tools struggle with latches because the "start time" of a path becomes fuzzy. Unlike a Flip-Flop, which has a definitive T-to-Q delay at the edge, a latch can start driving a path at any point during its transparent phase. This leads to Cycle Stealing, where errors in one part of the chip can cascade through three or four subsequent clock cycles.
3. When Latches become Indispensable
If they are so dangerous, why does every modern processor from Intel, AMD, and Apple use them? The answer is High-Performance Optimization.
A. Clock Gating (ICG)
To save power, we shut down clocks to idle blocks. However, a simple AND gate with a clock can cause "runt pulses" (glitches) if the enable changes while the clock is high. The standard industry solution is the Integrated Clock Gating (ICG) cell, which uses a level-sensitive latch to synchronize the enable signal to the low-phase of the clock, ensuring the gated clock always starts and stops cleanly.
B. Time Borrowing
In a Flip-Flop design, if a logic path takes 10 picoseconds longer than the clock period, the design fails. With latches, we can borrow time. Since the latch is transparent for half the cycle, a slow signal can "leak" into the next cycle's time. As long as the next logic path is fast enough to "pay back" that time, the chip continues to function perfectly at frequencies that would otherwise be impossible.
4. Best Practices
- Use Specific Blocks: Always use
always_ffandalways_comb. These keywords tell the tool your intent; if you accidentally infer a latch in analways_combblock, the compiler will throw an error immediately. - Explicit Intent: If you truly need a latch, use
always_latch. This documents the design for future engineers. - Closed Conditions: Always provide an
elsefor everyifand adefaultfor everycasestatement.