Structural analysis cannot tell a deliberate reset crossing from a bug unless somebody writes down which is which. Reset intent is that written record: every reset, the domain it defines, and how the domains release relative to each other.

What reset intent lists

One row per reset. If any column is unknown, the intent is incomplete and analysis waits.

Reset domains and their relationships

A reset domain is the set of registers that share one reset and one release behaviour. Two registers on the same reset net but released through different synchronisers belong to different reset domains, because they can come out of reset on different cycles.

A small example: a core domain and a peripheral domain where the peripheral must not leave reset until the core clock and reset are stable. The intent records the core reset at rank 1 and the peripheral reset at rank 2 with the core as its dependency. The analysis then checks that the peripheral release is held until the core release has completed, instead of guessing.

What the checks and the review look for

The checks map every flip-flop to exactly one reset domain and flag each crossing where reset or reset-released data moves between domains. The review checks the intent itself: every reset port on the boundary has a row, every rank has a reason, and no register is left unmapped. An unmapped register is a defect in the intent, not a pass.

Related topics

• The RDC signoff flow

• Classifying RDC findings

• RTL: Reset strategies