Reset defines how the system starts again
Reset can look like a small branch in a VHDL process. At system level, it decides how state becomes known, how blocks restart, and what happens to incomplete work.
I want those decisions to be explicit before integration. Which blocks reset together? Which clock must be running? What state can remain invalid? When is the system ready to accept data?
There is no single reset style that is best for every register. The right architecture follows the device, clocking, interface requirements, and recovery behavior.
Synchronous and asynchronous reset serve different needs
A synchronous reset is recognized on an active clock edge. It fits naturally into a clocked design, but the clock must run and the request must be present long enough to be sampled. An asynchronous external request cannot simply be assumed safe because the receiving process uses a synchronous reset branch.
An asynchronous reset can assert without a clock edge, which is useful when the clock is stopped or not yet available. Its release can violate recovery/removal requirements if it happens too close to the receiving edge. Reset pulse-width requirements still apply.
Device resources also have supported reset modes and inference rules. Reset choices can influence timing, routing, and the ability to use efficient DSP or memory implementations. I choose behavior that the system needs and check the mapped result.
Asynchronous assertion, synchronous local release
A common solution for an asynchronous reset request is to assert locally without waiting for the clock, then release through a synchronizer clocked by that domain. The synchronizer reduces the chance that uncertain release timing propagates into application logic.
A reset released with clock A is not automatically safe for unrelated clock B. Each domain needs appropriate local release handling. If its clock remains stopped, its local reset remains asserted until enough valid edges occur.
Within a domain, blocks that must restart together normally share a deliberate local reset arrangement. Independent synchronizers can release on different cycles. The reset-domain article provides the detailed VHDL example and explains the release sequence.
Reset-domain crossing is not only a clock-domain issue
Two blocks can share a clock and still belong to different reset domains. If one resets independently, its outputs can change while the other block remains active. The receiving logic must not interpret stale or reset-induced values as a valid transaction.
With asynchronous assertion, those changes may also occur away from the receiving clock edge. The required protection depends on the signal and protocol: isolation, coordinated resets, CDC-safe communication where needed, and explicit validity or readiness rules.
Adding a two-flop synchronizer to every data bit is not a general solution for a bus or transaction. I define how the boundary behaves during reset and restart, then verify that contract. Reset-domain analysis complements the CDC review.
Initialization and reset are different responsibilities
Reset does not have to clear every datapath register or memory location. Often the control state and valid flags can be reset while data remains ignored until it has been written correctly.
For example, a capture memory can retain unspecified old contents while a valid flag prevents display or consumption. The system marks the recording valid only after a complete new capture. That saves the requirement to clear the whole memory immediately.
If software must read a defined memory image after reset, that initialization must actually happen before readiness is asserted. Device-supported configuration initialization, runtime clearing, and a later partial reset are different events; one should not be assumed to provide the others.
A released reset does not mean ready
Clock managers, interfaces, memories, and controllers may need startup time. I hold traffic off until the required local initialization is complete and readiness has been communicated safely to the other participants.
Clock-lock indications need handling according to the clocking and reset controller’s guidance. Clock startup must not depend on logic that can only run after that same clock has already released reset.
In a multi-clock system, coordinated readiness is more useful than expecting every domain to leave reset on the same instant. The design should tolerate the permitted difference in startup times.
Partial reset needs an in-flight transaction policy
If reset arrives during a transfer, I define whether the operation is discarded, retried, or completed before reset. Queued commands, response IDs, interrupts, and buffer ownership may need coordinated cleanup.
A handshake can otherwise restart with an old request or acknowledgement. An asynchronous FIFO can lose its shared pointer relationship if one side is reset outside the supported reset procedure. I follow the IP’s documented requirements and do not assume one-sided reset is safe.
The same policy must be visible to software. A driver needs to know whether pending work is canceled, how errors are cleared, and when it may submit work again.
Verify reset as a feature, not just a startup pulse
- Reset at startup and during representative active operations.
- Release at different clock phases and domain frequencies.
- Stopped clocks, restart sequencing, and repeated resets.
- Independent reset groups and interactions with blocks left running.
- No valid output or stale transaction before readiness.
- Implementation checks for synchronizers, reset distribution, pulse width, and recovery/removal timing.
RTL simulation checks the exercised sequencing and protocol behavior. It cannot establish analog metastability reliability. I combine it with device-specific constraints, CDC/reset-domain analysis, timing review, and relevant hardware checks.
AMD’s reset methodology guidance explains important physical tradeoffs. My aim is a reset architecture that returns the whole system to a defined, usable condition, with a clear path from reset to normal operation.