FPGA reset asynchronous or synchronous?

[Altera_Forum]

I normally reset all my d-types using their asynchronous input. I have done this for a long time without any issues.  

 The other day I was chatting to someone else and he said it is best practice not to use the asynchronous input but use a synchronous reset instead. But he didn't know why. The problem I see with synchronous reset is it could make the set-up and hold time longer.  Does anyone have any comments or advice on this subject?  Thanks in advance.  geobyjmh

[Altera_Forum]

If you have a asyncronious reset, which also clears asynchrone you might end up with some meta-stability after the reset, and you don't want this. You can prevent this by using a synchrone reset, but this gives troubles if you have a reseet affecting the clock, or timing problems. The solution I use is to trigger the reset asynchrone and then clock the clear through two flip-flops to get it synchronised. In this way you have the best of both worlds. 

[edit] attached is a RTL-viewer schematic of the circuit, but than with a dual-input high to trigger the reset. [/edit]

[Altera_Forum]

just have the async reset connected to a synchronous signal, then no problem with timing (or what pierter suggested above). 

Altera flops have no sync resets, so their behaviour has to be emulated with a mux. But it will make your code more portable, and slightly easier to read.

[Altera_Forum]

Thanks PietervanderStar. I like your solution! Your RTL looks interesting and is worth some considering.  

 Does metastability affect the asynchronous input on a d-type? I didn't think they did because they are independent of the clock.  However I think you solution is elegant and will probably start using it.

[Altera_Forum]

--- Quote Start ---   Does anyone have any comments or advice on this subject?   --- Quote End ---   The choice of which HDL style to use should be influenced by the underlying architecture of the FPGA, or FPGA resource.  For example, I recall an FPGA component (DSP block in Xilinx I think) that does not have an asynchronous reset. If you tried to code one, you either ended up with an error, or "extra" logic.  The registers in Altera devices have asynchronous reset ports, so you should write your code such that it uses them. The caveat is that you need to synchronize the reset sources to each clock domain in your FPGA, i.e., use the reset synchronizer PietervanderStar posted. Cliff Cummings has several tutorials on synchronizing reset. TimeQuest will analyze your synchronized reset paths via the reset recovery and removal timing.  If you write your code for a synchronous reset, then Quartus will create logic to implement your synchronous reset, i.e., you will needlessly use up LUT inputs. So the "cost" of using an incorrect style, is a larger design, and a potential to increase the combinatorial path in your design.  I'd recommend reading the Cliff Cummings papers on resets ...  http://www.sunburst-design.com/papers/  Cheers, Dave

[Altera_Forum]

Thanks Tricky. How would have though a reset signal could be so interesting :-)  

 From what you have written does that mean you would use a mux on every flip flop in a design to give them all synchronous reset?

[Altera_Forum]

Thanks Dave - I will have a read of the papers. They look interesting.

[Altera_Forum]

There is a dedicated, LAB-wide synchronous reset, so it's not going to use up part of your LUT, but synthesis does try to push LUT logic onto the synchronous reset if it's available, so the net sum is it can make your design larger and slower if you have a synchronous reset. I have worked with users that have switched entire designs from synchronous to asynchronous, and the area savings was <2% and the performance savings was less than normal seed noise, so though I recommend asynchronous, it's not something that usually makes or breaks your design. (I've had users debating if they wanted to convert hundreds of old files that they really don't want to touch, and evaluate it wasn't worth the work).

[Altera_Forum]

Thanks Rysc. I found your comment very interesting. There is a lot more to reseting that I have ever considered. I have also been doing a little reading on the subject, hopefully I can will find time to summarize it. However this thread has provided some very useful pointers.

[Altera_Forum]

The recovery and removal section on page 65 should talk about reset structures: 

http://www.alterawiki.com/wiki/timequest_user_guide

[Altera_Forum]

--- Quote Start ---  There is a dedicated, LAB-wide synchronous reset, so it's not going to use up part of your LUT  --- Quote End ---    Hi Rysc, just curious about above point. Wouldn't the lab wide reset also need gating?

[Altera_Forum]

Sorry, could you elaborate what you mean by gating?

[Altera_Forum]

--- Quote Start ---  Sorry, could you elaborate what you mean by gating?  --- Quote End ---    For synchronous reset the reset signal is ANDed with D input such that either D passes or reset value. This is required per each flip. So whether a lab wide route is available or not this gating will be needed (unlike wiring rst to the async port)

[Altera_Forum]

There is some dedicated hardware for doing the synchronous clear, but it's in there already. Actually, at least on older architectures, it wasn't a simple AND gate. Instead, something else was done to give the D input priority, so that it wasn't slowed down by the synchronous clear, which an AND gate would do. I don't remember the exact details and don't know if it's still done. It was probably only a 100ps savings to your datapath, but an interesting way to do it.  

(I believe in the Resource Property Editor the synchronous clear is shown as an AND gate, but that may be to simplify the picture)

[Altera_Forum]

Ok thanks. I imagine some tricky ways could be done such as switching off D inputs at some level and applying tristate on reset signal at source.

[Altera_Forum]

Thank you for all your replies. This has helped me enormously :-)  

 Based on this post I did some searching and PietervanderStar suggested the best approach to resetting your FPGA.  I have written a blog post on what I have found: http://geobyjmhembeddedengineer.blogspot.co.uk/2014/06/reseting-my-nios-ii.html  But the most helpful reference is the Altera - Recommended Design Practices found: http://www.altera.co.uk/literature/hb/qts/qts_qii51006.pdf  A summary is as follows:  The asynchronous reset is the simplest to implement and is probably the most common type of reset used in an FPGA design. The advantage of this kind of reset is it does not need to insert any extra logic in the data path and therefore will not inadvertently increase the logic layers between d-types in an RTL stage. This means that asynchronous reset will not impact on the data arrival time to a register input. The other big advantage of an asynchronous reset is that the reset will take effect immediately i.e. it is not dependent on the clock.   But there is a very big disadvantage to using asynchronous resets! You cannot guarantee that the resets for all the d-types will be released in the same clock cycle. This create the small possibility of you design not coming out of reset in the way that was predicted. This could cause an intermittent fault that is tricky to track down.  However there is a down side to synchronous resets. Your design will be more complex and you create the risk of adding additional gate delays to accommodate the reset signal. This will produce a negative impact on the d-types set-up slack time.  This design avoids the potential problems associated with synchronous reset and purely asynchronous reset. The reset is applied asynchronously and immediately. It also does not create the additional logic we have seen with the synchronous design. However the one big advantage is that when the reset is released, it is synchronous to the clock. This mean that all the registers will be reset in the same clock cycle. You can also use static timing analysis to prove your timings.    Thanks again for all your help  geobyjmh