Reconvergence findings survive every round of waiver cleanup, which tempts teams to treat them as tool noise. They are the opposite: a structural analysis cannot see intent, so when it reports that two synchronised signals meet, it is asking the one question only the designer can answer — is every combination the skew window can produce acceptable?
It identifies every synchroniser and the source-domain signal feeding it.
It traces each synchronised output forward through destination logic to the first gate where two such traces meet: the convergence point.
It reports the meeting point with the two source signals, the two path depths, and the skew between the arrivals.
It does not decide correctness. Same-cycle arrival is a timing property of a particular build, and the analysis reports the structure that makes the outcome timing-dependent.
Reviewer question | Acceptable answer | Not an answer |
|---|---|---|
Which combinations can the skew window show? | An enumeration from the source protocol, showing each reachable mixture is benign | “The synchronisers are clean” |
Is the meeting logic insensitive to the order? | A reason the gate output is the same for every arrival order | “It is only one cycle” |
Does the protocol prevent the mixture? | Mutual exclusion or sequencing proven in the source domain | “Simulation never hit it” |
A waiver on a reconvergence finding therefore needs design evidence: the protocol argument, the insensitivity proof, or the pointer to the fix. A clean simulation log alone does not answer a structural question, because simulation exercises one alignment while silicon explores them all.
The timing question: whether the OR output differs between arrival orders. Clean synchronisers promise settled bits, not same-cycle arrival, so the finding stands until the designer shows the OR output is correct for every mixture the skew window allows.