Reset puts hardware into a known state. Pick one strategy per project and apply it consistently.
Async vs sync
| Style | Pros | Cons |
|---|---|---|
| Async assert | Immediate; classic FPGA negedge rst_n |
Deassert must be timed vs clock |
| Sync reset | Treated as data; simpler STA | Needs active clock to reset |
Common FPGA pattern: async assert, synchronously deassert through a reset synchronizer so flops leave reset cleanly.
Polarity & naming
- Prefer active-low
rst_n/reset_nin many FPGA templates. - Name polarity in the signal — never rely on tribal knowledge.
What to reset
| Usually reset | Often skip |
|---|---|
| FSM state | Large datapath pipelines |
| Ready/valid control | Inferred RAM contents (init separately) |
| Counters / pointers | Debug-only shadows |
Resetting everything costs routing and fanout; reset what defines legal behavior.
Release sequencing
- Clocks stable
- Reset asserted long enough
- Reset deassert synchronized to each domain
- Then release traffic (valid, grants)
Multi-clock chips need per-domain reset sync — one global async net is not enough alone.
TB hygiene
Drive reset at time 0, hold several clocks, release, then stimulate. Check that outputs leave X / match idle after reset in simulation.