reset sync design logic

[Altera_Forum]

I have a question regarding reset sync logic . 

  first of all what I understood about requirement of reset synchronization in design :   - Reset will be asynchronous in nature.   - It is not an issue if reset assertion in design will not be on active edge.   - But when de-asserting reset at that time it must be on active edge of clock.   - If de-assertion is asynchronous in nature then it may case design output to stuck into metastable-state   - So to prevent it reset synchronize is used.   ( I would request to all member to clarify me about need of reset synchronize if i understood something wrong !!! )   - When I google about how to design reset synchronize module I just confused with the way they have synchronize reset with clock.   //================================================================================================================================== // reset synchronize logic snippet I found from website  //==================================================================================================================================   module reset_synchronize  (  input clock_i,  input resetn_i,    output sync_resetn_o );    logic resetn_f1;  logic resetn_f2;    assign sync_resetn_o = resetn_f2;    always_ff @(posedge clock_i or negedge resetn_i)  begin  if(~resetn_i)  begin   resetn_f1 <= 0;  resetn_f2 <= 0;  end   else  begin  resetn_f1 <= 1'b1;  resetn_f2 <= resetn_f1;  end   end   endmodule    //============================================================================================================== // what I observed from above snippet & my question  //==============================================================================================================    - have used two flip-flops ( no idea for what they have used second flip-flop as my reset will sync only need 1 flip-flop )   - when reset_n is there will be keeping "resetn_f1" & "resetn_f2" zero ( I am okey with this !! )   - when reset_n = 1 then will be giving "resetn_f1 == 1" & "resetn_f2 = resetn_f1"   Q1 : whay they have used "resetn_f2" as with simple "resetn_f1" also I can have de-assertion of reset_n on clock edge.

[Altera_Forum]

synchronising an async signal requires at least two stages of sampling. When you say it should be one register then you are not looking at the issue of edge violation but you are only thinking of sampling. 

 The first register will be violated from time to time but it is hoped that its Q output will settle before next register samples. However the second register may be violated (this is very low probabilty given by MTBF). Three stages will improve MTBF dramatically such that a failure may occur once every million years? just guessing but it should be that far.  To synchronise an async signal there are two designs, type1 passes signal directly through D register of first stage (such as dc fifo pointers being passed from one clock domain to another while data itself is left in memory cell or register till pointer arrives then sampled).  Type2 is the one you posted. It is used for reset (and is called reset synchroniser). The difference is that the async signal is not passed through D input of first stage but rather it is used as async reset for both stages and the first stage samples from constant logic '1'. This is believed to be more safe and the explanation given by various sources is vague but my thoughts are as follows:  In type1 the second register may be unlucky and get violation if its first register did not settle within one clock period. In type2 imagine reset violated register1, its input is not changing (constant '1') but its output needs to change state and so will get violated. reset and clock then travel together to second register (before data arrives) and it does not change state as input is '0' and output is '0' and so will not be violated (but will be violated if data is too early-unlikely). on the next clock edge the first register will sample safely its constant input and so will the second register

[Altera_Forum]

I will add that you will have to take a look at the generated hardware to ensure the curcuit is the one you want. I found quartus only generated what I wanted if i inverted some of the logic. I think this is the optimizations at work. But check you get what you want.

[Altera_Forum]

Hello Kaz, 

 Thank you for very good explanation. Could you help me to understand following sentence more clearly?    --- Quote Start ---  In type2 imagine reset violated register1,  --- Quote End ---   Could you elaborate this? Do you mean reset is released during 'setup' or 'hold' period of register 1 and hence it would take time much than Tco ( Tco - clock to output delay ) for register1 to provide stable output?  Regards, Bhaumik

[Altera_Forum]

--- Quote Start ---  Hello Kaz,  Thank you for very good explanation. Could you help me to understand following sentence more clearly?   Could you elaborate this? Do you mean reset is released during 'setup' or 'hold' period of register 1 and hence it would take time much than Tco ( Tco - clock to output delay ) for register1 to provide stable output?  Regards, Bhaumik  --- Quote End ---      not type2 but Yes, type1 sync design violation is that of tSU/tH of reg1 (and yes tCO will be unpredictable) My thoughts on “micro-details” of events inside a clocked flip is that there are two issues:  1) Any D input has to be sampled at clock edge. Hence the input D should not be in transition near clock edge or else sampling will not “see” if input is high or low as it could be in gray area of signal level. If input D is not changing then above does not apply obviously  2) The flip has to change Q output state. If above violation in 1 occurs then output may go wrong for sometime  That is 1+2 implies tSU/tH case  In case of type2 snc design (async reset), only issue 2 above applies as input D is not sampled until reset release. So if Q output state has to change during reset deassertion we could get the flip in same problem. If Q output state does not change then this violation is irrelevant.   This is recovery/removal case  However, I am not sure why both registers are reset as I think first register can be reset only and then the type2 reset synchroniser becomes very close to type1

[Altera_Forum]

If you want more information, you can takr a look at this thread, where the pros and cons are discussed. 

http://www.alteraforum.com/forum/showthread.php?t=45135 (http://www.alteraforum.com/forum/showthread.php?t=45135&p=186549&highlight=#post186549)

[Altera_Forum]

@ Kaz, 

 Thank you very much for your reply.  @ PietervanderStar, Thanks for sharing that link. It is having very good discussion.  @ others, Here is one another link ( http://www.alteraforum.com/forum/showthread.php?t=49992 ) where kaz has provided good description about similar topic.  Cheers, Bhaumik

[Altera_Forum]

Could you check the link? The thread id is missing, so it does not work. 

And for the last link, I think it is incomplete, or incorrect

[Altera_Forum]

Thank you all for such a detail replay.

[Altera_Forum]

--- Quote Start ---  Could you check the link? The thread id is missing, so it does not work. And for the last link, I think it is incomplete, or incorrect  --- Quote End ---    Thank you for pointing out that mistake. I have corrected first link. Second Link was added by mistake in previous post and hence I have removed that.  Regards, Bhaumik

[Altera_Forum]

@ Kaz, 

   --- Quote Start ---  However, I am not sure why both registers are reset as I think first register can be reset only  --- Quote End ---   According to me, we must reset second register also. Consider the case when clock has been lost due to some issue and meantime, we need to reset our design. In this case, if we do not use reset for second register, our design will not get reset. So, by using reset for second register, we ensure that 'asynchronous' assertion benefit of reset ( design can be reset even in the absence of clock ) is preserved.   Feel free to share your thought.  Thank you, Bhaumik

[Altera_Forum]

--- Quote Start ---  @ Kaz,   According to me, we must reset second register also. Consider the case when clock has been lost due to some issue and meantime, we need to reset our design. In this case, if we do not use reset for second register, our design will not get reset. So, by using reset for second register, we ensure that 'asynchronous' assertion benefit of reset ( design can be reset even in the absence of clock ) is preserved.   Feel free to share your thought.  Thank you, Bhaumik  --- Quote End ---    That makes perfect sense. It also explains why reset synchroniser is safer than just passing reset through D input(data synchroniser) Thanks for sharing