A CDC report answers three questions in order: how many problems of each kind exist, which crossings they are, and exactly what each crossing looks like. Every report organises itself around those three levels, whatever its formatting.
First comes the summary: counts per rule class, such as unsynchronised crossings, combinational logic before a synchroniser, multi-bit crossings without a protocol, reconvergence, and reset-domain findings. The summary is the signoff snapshot: it tells you at a glance whether you are looking at a handful of findings or a systematic problem.
Second come the per-class listings: every flagged crossing under its rule, usually with an identifier, the source and destination hierarchy, and the rule that fired. This is the work list. Third comes the crossing detail for each entry: the source clock and destination clock, the traced path between them, and the synchroniser or protocol the analysis detected along the path, if any.
Reports differ in wording, so read the excerpt below as an illustration of structure, not of any real report format. It is fabricated and every number is illustrative.
Illustrative CDC summary (fabricated excerpt, not a real report):
Rule class Count
Unsynchronised single-bit crossing 12
Combinational logic before synchroniser 5
Multi-bit crossing without protocol 3
Reconvergence after synchronisers 4
Reset-domain crossing 2
Total 26
Crossing detail for entry U-007 (illustrative):
source clock : clk_a (100 MHz)
dest clock : clk_b (50 MHz, asynchronous to clk_a)
path : u_ctrl.req -> u_sync.u_q1/D
detected : two-flop synchroniser in clk_b, no logic between stages
verdict : synchronised level crossing; review quasi-static intentField | What it tells you | What looks wrong |
|---|---|---|
Source and destination clocks | Whether the crossing is genuinely asynchronous. | A missing or wrong clock, or two clocks claimed synchronous without justification. |
The traced path | Which net actually crosses, and through what logic. | Combinational cells between the boundary and the synchroniser input. |
Detected synchroniser or protocol | Whether the analysis recognised the intended structure. | Nothing detected where the design intent claims a synchroniser exists. |
The last row is the most useful mismatch in debugging: when the intent says a synchroniser is there and the analysis sees none, either the structure breaks a rule the recogniser needs, such as logic between the stages, or the intent points at the wrong instance. Both are cheap to confirm in the schematic.
Either the structure violates a recognition rule, for example combinational logic between the stages, or the intent points at the wrong instance and the real path has no synchroniser.
With the summary counts: five classes with small counts suggest a short per-class pass, while one dominant class suggests a single systematic cause worth grouping before touching any detail.