Stage count is the one MTBF lever RTL owns, so signoff reviews it explicitly. The guidance below is qualitative: project policy sets the actual thresholds from library data, but the shape of the decision is the same everywhere.
Situation | Usual choice |
|---|---|
Moderate destination clocks with ordinary reliability needs | Two flops are accepted almost everywhere. |
Very high destination frequency (around 1 GHz and above) | Three flops are commonly asked for, because the period leaves little resolution time. |
Safety or high-reliability requirements, long operating life | Three flops, so that one analysis covers worst-case conditions with margin. |
A chip with very many synchronisers | Consider three on the fastest clocks: chip-level failure rate is roughly the per-synchroniser rate times the count. |
More flops buy settling time and nothing else. They do not make several bits arrive together, so a multi-bit word still needs a protocol. They do not hold a short pulse still, so a pulse narrower than the destination period still needs stretching or a toggle scheme. And they do not order resets or remove reconvergence.
Extra stages also cost one destination cycle of latency each. For a plain level crossing that cost is invisible, but in a handshake loop each added stage delays every transfer in both directions, so the protocol budget must count it.
Whether two stages still leave enough resolution time at the shorter period, using library τ and T_W. The likely outcome is a third stage on those crossings.
No. Three stages settle each bit beautifully and still let the bits resolve to a mix of old and new values. Word safety needs Gray code, a handshake, or a FIFO, not more stages.