--- Quote Start ---
Synchronous reset is recommended to ensure that all logic comes out of reset at the same time.
--- Quote End ---
It might be better to use an asynchronous reset with recovery/removal analysis. A synchronous reset adds an additional signal to the LUT(s) in front of the register, potentially increasing the number of LUTs required and the number of levels of logic compared to an asynchronous reset.
Recovery and removal for an asynchronous reset are similar to setup and hold for a synchronous reset. Positive slack for recovery and removal guarantees that the reset deassertion is recognized at the same clock cycle for all the registers using the same reset signal (for example, ensures that all bits of a state machine come out of reset at the same time). Even though a synchronous kind of timing analysis can be done for asynchronous resets to verify the reset has the needed timing with respect to the clock, the resets are still called asynchronous because they use the asynchronous clear or asynchronous load control signals of the registers. If the reset signal coming into the FPGA is truly asynchronous to the clock, then for each clock domain (or set of clock domains that are synchronous to each other) the reset input signal should be passed through synchronizing registers before it is used as a reset internal to the FPGA.
--- Quote Start ---
But often in some process we dont need the reset.for example, the data flow sequence in,the uncertain will be flushed out soon.
But the rest cost global resource,and make some optimize difficult(some special element have no async reset).
so whether use reset,when to use, global or local?
--- Quote End ---
You're correct that you don't need a reset, either asynchronous or synchronous, for logic that will have any initial unknown or incorrect data replaced with good data before the data is actually used. You might still want a reset for that kind of logic though to make it easier to initialize things for simulation. If you choose not to reset that kind of logic, just don't include a reset for it in your source files. It's fine to connect the reset only to the logic that must have it for correct operation.
For use of a global resource, the timing is often better with a nonglobal reset regardless of whether it is setup and hold timing for a synchronous reset or recovery and removal timing for an asynchronous reset. This is true even for high-fan-out resets. The global insertion delay can be big relative to the clock period. To know whether the timing is better with the global insertion delay or with lots of nonglobal interconnect, try it both ways. Some designs need the reset to be nonglobal and also need it to be replicated so that all the destinations in a given area of the device are driven by a copy from a nearby reset register.
Recovery and removal analysis for an asynchronous reset is necessary even if global routing results in zero skew on the reset. To guarantee all registers exit reset simultaneously, you must make sure the deassertion happens at the correct time with respect to the clock even if global routing makes it happen at exactly the same time for all the registers.
Honored Contributor
