Tearing can be read as a timing problem: the destination clock samples each bit at a slightly different effective moment because of wire and cell delay differences, and a transition that falls inside the spread of those moments is captured inconsistently.
For one bit, the vulnerable moment is its own setup/hold window. For a word, the vulnerable span is the whole spread of arrival times across bits plus the sampling window: any transition inside that span can tear. The wider the skew between bits, the larger the fraction of transitions at risk.
Contributor | Effect on the word |
|---|---|
Wire delay differences between bits | Spread the arrivals; the dominant term on long routes. |
Cell delay differences in per-bit flops | Add a smaller but always-present spread. |
Clock skew at the sampling flops | Shifts each bit's effective sampling moment. |
Source transition rate | Decides how often a transition lands inside the span. |
Matching wire lengths can shrink the skew, but the residual depends on routing, corners, voltage, and temperature, and it must be re-proven after every layout change. Worse, matched skew only narrows the vulnerable span; the word still tears whenever a transition lands inside it. Skew control is a useful hardening step, never the safety argument. The safety argument is always a protocol that tolerates arbitrary skew.
Structural analysis does not measure your skew; it checks that a protocol exists. A matched-layout bus with per-bit synchronisers and no protocol is still reported as an unsynchronised multi-bit crossing, whatever the layout claims.
No. It halves how often a transition lands inside the span, but every transition inside it can still tear. Only a protocol removes the bug rather than thinning it.
Any real protocol: Gray code for stepping counters, a handshake or load pulse holding the data stable, a FIFO for streams, or dual-clock RAM. All of them tolerate arbitrary skew by construction.