reset or not

[Altera_Forum]

There is a lot suggestions on how to use reset(Asyn or sync) or whether use reset. 

As i known,the most reason why we use reset(or set) is to force the state clearly.i.e state machine.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? Now,i always use global async reset for my project.but now i want to know its there any choice.whats your opinion? if i can use local reset & global reset togther(i.e state machine use global async reset,dat flow no reset).

[Altera_Forum]

It is recommended ot always use a reset as this ensures that logic comes up in a defined state. Additionally, Synchronous reset is recommended to ensure that all logic comes out of reset at the same time. This is especially true with Multiple clock domain designs

[Altera_Forum]

--- 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.

[Altera_Forum]

What Brad said is particular, he is all right. 

In a word , we should always give attention to the time slack, positive but not negative no matter synchronous or asynchronous reset we use. Asynchronous reset may make slack tensional, which depends on your logic the reset signal passed through. What does the lines below i quote in your post mean? I don't understand them clearly. "Recovery and removal for an asynchronous reset are similar to setup and hold for a synchronous reset." Could you explain them ? Thanks very much.

[Altera_Forum]

--- Quote Start ---  What does the lines below i quote in your post mean? I don't understand them clearly. "Recovery and removal for an asynchronous reset are similar to setup and hold for a synchronous reset." Could you explain them ?  --- Quote End ---     From the Quartus handbook, Volume 2, Section III, Chapter 8:    --- Quote Start ---  Asynchronous Control Signal Recovery/Removal Analysis  This option determines whether you want the software to analyze the results of recovery and removal checks for paths that end at an asynchronous clear, preset, or load signal of a register. recovery time is the minimum length of time an asynchronous control signal, for example, clear and preset, must be stable before the active clock edge. removal time is the minimum time an asynchronous control signal must be stable after the active clock edge. Recovery and removal requirements are similar to setup and hold time requirements, respectively.  --- Quote End ---