I've been working with fpgas for years, and always used synchronous resets for every parts (that need it) of my circuits. It helps the circuit to be globally reset at a given clock cycle.
However, I was told that in ASIC circuits, people tend to use asynchronous reset everywhere. I'm wondering why, and if it is the case in some fpga designs too. I would love to hear professional opinions.
Thanks
There seem to be a lot of views on this one.
Asynchronous assertion, synchronous deassertion is said to be good practice. This avoids the issue of the clock not running (or running too slowly to capture the reset signal) on synchronous assertion, and possible metastability on asynchronous deassertion.
You would use a reset synchroniser (two FFs) with the output tied to the rest of the designs resets:
Couple of discussions:
Async and sync reset
Letters On Sync vs. Async Resets
I would favor an asynchronous reset over a synchronous reset for a few reasons (in no particular order):
Ultimately I don't think any of these issues are show-stoppers, but they would definitely contribute to a strong preference of asynchronous reset on ASICs.
Asynchronous reset with synchronous de-assertion works very well. As mentioned above, async reset flops are smaller and don't require a clock active to ensure reset, so you can force a part into reset (usually a known, low power state) with just power and a single hard wired pin or power-on reset.
If you really want to dig into this, you might read over Cumming's papers on this, in particular:
http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf
Cheers.
Another approach, which would seem even safer than the 'async assert/sync release' approach, would be to have an asynchronous reset detector (much as described elsewhere, with asynchronous 'assert' and synchronous 'release'), but have the output from that gate any outward-facing I/O devices without asynchronously resetting anything (other than the latch in the detector itself). If one uses two asynchronous reset detectors, one for I/O lines and one to feed the synchronous reset detector, and if one designs the one for I/O lines so that it will only be tripped by reset pulses which are sound enough to reliably trip the main detector, one may avoid even having the outputs glitch in cases that aren't going to reset the CPU. Note that if one does this, a legitimate-length reset pulse will reset the outputs asynchronously, but a runt reset pulse may not cleanly reset the outputs until two clock cycles later (if the runt reset pulse is followed by a real one before two clocks have arrived, the real reset pulse will reset the outputs even if the runt pulse didn't).
Another thing to consider is that systems often have some registers which are not supposed to be affected by a reset. If an asynchronous reset could hit circuitry which writes to those registers, it would be possible for a reset pulse which arrives at the wrong time to clobber those registers, even if it's a clean (non-runt) pulse. For example, if code is trying to write to address 1111 and an async reset which arrives just before a clock pulse forces one of the address latches to zero just as the clock pulse is arriving, that could cause an erroneous write to address 1110. While one could use multiple internal reset lines with combinatorial delays to ensure that register writes were disabled before the address got clobbered, using synchronous internal reset logic avoids the issue altogether.
BTW, here's a circuit illustrating the concept. Near the lower-left corner are two logic inputs for reset. One will generate a "clean" reset pulse, and the other will generate a really icky one. The yellow LED indicates main system reset; the cyan LED indicates I/O enable. Hitting a clean reset will cause an immediate "reset" of the outputs; hitting an icky reset will either cause a delayed reset of the outputs, or leave them unaffected (in the simulator, there's no way to cause the 'leave them unaffected' case).
As an experienced engineer (3 years with FPGA design and embedded systems), I'm telling you that you need to check the FPGA's datasheet and user guide. Its not a simple answer.
You have to make your design FITs the FPGA type you chose. Some FPGAs have FlipFlops that were designed for Async reset, some are designed for Sync reset.
You have to check the FPGA user guide for what type of FlipFlops you have.
The Implementor/Mapper will chose dedicated routes for your reset (code can run at higher freq and takes less space) if you match your code with the FPGA primitives type.
Your design will work in ANY case, but sometimes the FPGA Implementor will go out of its way to make your logic work (adds more logic), but that will cause lower maximum frequency and/or more FPGA ressources.
Example: tested with Xilinx's ZYNQ (FPGA is designed for synched reset - see primitives user guide). By changing reset from async to sync, max stable frequency went from 220MHz to 258MHz and so I passed my frequency margin.
Also I might add that the Implementor does not know what is a clock and reset signal. It assigns flipflop pins to signals by ORDER, not by name. So in some FPGAs, the implementor choses the first signal after "process() begin" in VHDL as the clock, in some as the reset, depending on what FPGA the implementor is set to.
