Third-party and reused IP arrives with its own reset architecture, its own assumptions, and documentation of varying honesty. The integrator cannot see inside encrypted or legacy IP, so reset signoff for IP is a contract check: does the documentation state every reset requirement, and does the chip meet all of them?
Item | What good looks like | If it is missing |
|---|---|---|
Reset ports and polarity | Every reset port named with polarity and assertion style. | Probe the behaviour in simulation; never guess polarity from the name. |
Synchroniser included or required | States whether release synchronisation is inside the IP or expected outside. | Assume it is required outside and add it, then verify. |
Minimum assertion time | A stated number of cycles or time the reset must be held. | Hold reset conservatively long and confirm in simulation. |
Release ordering | Which resets must release first and what the IP needs from its neighbours. | Sequence the IP last out of reset and check its outputs stay safe. |
Reset values of visible state | Status and configuration registers defined at and after reset. | Read them back after reset in simulation before relying on them. |
Behaviour during reset | What outputs drive while reset is asserted. | Treat outputs as unknown during reset and isolate downstream logic. |
Structural checks treat undocumented IP resets as crossings with unknown release: findings, not passes. The review walks the checklist row by row for each IP instance, because two instances of the same IP in different reset domains can need different answers. Reused internal IP gets the same treatment whenever its original assumptions are unavailable or its new context differs.
Assume it is required outside: add the synchroniser, verify the release sequence in simulation, and record the decision as the working contract.
Two. Each instance has different neighbours, ordering, and synchronising clocks, so each needs its own row-by-row check.