A structural run reports crossings, not verdicts. Classification turns that inventory into work: each finding is mapped to a generic class, the class suggests a severity, and the severity decides whether the answer is a fix or a waiver with evidence. Learn the classes once and every report reads the same way.
Finding | Meaning | Severity thinking | Typical fix |
|---|---|---|---|
Unsynchronised crossing | A signal crosses domains with no synchronising structure | Defect until proven otherwise; the highest priority | Add a synchroniser, handshake, or FIFO stage |
Logic before the synchroniser | Combinational logic sits between the source register and the first synchroniser flop | Defect; glitches can be captured as data | Move the logic after the synchroniser or register the source cleanly |
Multi-bit crossing without a protocol | Several related bits cross with independent synchronisers and no Gray, handshake, or FIFO discipline | Defect; bits resolve independently and the value tears | Gray coding, handshake, or FIFO depending on the data type |
Reconvergence | Synchronised signals meet again in downstream logic without protection | Defect unless the skew is bounded and proven safe | Restructure the logic or add a proven bound with evidence |
Reset crossing | A reset (or its release) crosses into another domain unsynchronised | Defect; release races the destination clock | Reset synchroniser in the destination domain |
Synchroniser misuse | A synchroniser exists but is used wrongly: fed by a pulse too short to sample, fanned out from the first flop, or shared across unrelated bits | Defect; the structure gives false confidence | Match the structure to the signal: stretch, toggle, handshake, or one synchroniser per independent bit |
The synchroniser structures named above are taught in the RTL course: synchronisers, CDC handshakes, and async FIFOs. This section assumes them and asks only whether each crossing has the right one.
Read unsynchronised crossings first: each is either a missing synchroniser or a missing setup statement, and both answers are cheap to determine.
Read logic-before-synchroniser and multi-bit findings next: these are design defects with known fixes, and they cluster where designers improvised.
Read reconvergence and reset crossings with the domain owners present: the fix often moves logic across a boundary, which needs agreement.
Read synchroniser misuse last: it needs the surrounding protocol to judge, so it is the slowest class per finding.
Severity is about consequence, not count. One unsynchronised reset release outranks fifty correctly classified quasi-static crossings, and the dashboard must never let volume hide that.
Logic before the synchroniser. Register the source in the source domain so the crossing carries a glitch-free flop output, or move the logic after the synchroniser.
Severity follows consequence: an unsynchronised release can put part of a domain into the wrong state on every power-up, while classified quasi-static crossings already carry their evidence. Counts measure work; severity measures risk.