Question about sync/async reset and recovery/removal

--- Quote Start ---

I understand most of the recommendation when implementing reset scheme is using asynchronous assertion and synchronous deassertion. My question is why do we need sync deassertion given that it is already analyzed using recovery/removal.

--- Quote End ---

Altera(not everbody) recommends that and is meant to help achieve recovery/removal timing requirements so the two are not alternatives.

--- Quote Start ---

Also, I am still confused how is the output of the double synchronizer considered synchronous as they are still feeding the aclr port of the Flip-Flops and will still be analyzed under recovery/removal instead of setup/hold.

--- Quote End ---

Which double synchroniser you refer to?

--- Quote Start ---

Altera(not everbody) recommends that and is meant to help achieve recovery/removal timing requirements so the two are not alternatives.

Does that mean it is not necessary to have a synchronous assertion since it has already been taken into account in recovery/removal?

Which double synchroniser you refer to?

--- Quote End ---

I was referring to the output of the synchronizer that feed into the aclr port of the system. Again, I do not understand why is it 'synchronous' since it is feeding the aclr port (which again is under recovery/removal)

http://1.bp.blogspot.com/_jwnl_zs6958/sdkgixi7uyi/aaaaaaaaawq/zvzv07l0pou/s320/sync_deass_async_***.jpg

If reset is not pre-synchronised it means it will be be de-asserted anytime and so it will fail timing. In fact Timequest cannot report on a path unless it is between two registers (including outside io registers).

The output of double synchroniser is synchronised since it is the D input that matters here.

D1 starts and stays as '1' from powerup then

when reset is de-asserted i.e. changes '0'=> '1' Q1 changes from '0' => '1' ( on clock edge but de-assertion can be at any time relative to clock edge) then

Q2 changes from '0' to '1' on next clock edge while reset has been '1' for one clock period.

Q2 is then used as reset for the system registers.

--- Quote Start ---

If reset is not pre-synchronised it means it will be be de-asserted anytime and so it will fail timing. In fact Timequest cannot report on a path unless it is between two registers (including outside io registers).

The output of double synchroniser is synchronised since it is the D input that matters here.

D1 starts and stays as '1' from powerup then

when reset is de-asserted i.e. changes '0'=> '1' Q1 changes from '0' => '1' ( on clock edge but de-assertion can be at any time relative to clock edge) then

Q2 changes from '0' to '1' on next clock edge while reset has been '1' for one clock period.

Q2 is then used as reset for the system registers.

--- Quote End ---

Does Q2 feed to the registers' aclr port of the rest system? I mean Q2 is used as async reset in HDL coding?

--- Quote Start ---

Q2 is then used as reset for the system registers.

--- Quote End ---

I understand this part, but again it is resetting the asynchronous part of the registers. Will this be analyzed as setup/hold or recovery/removal. If the latter, shouldn't it be considered asynchronous? My understanding is synchronous reset should be going through the D input of the registers.

Thanks.

--- Quote Start ---

I understand this part, but again it is resetting the asynchronous part of the registers. Will this be analyzed as setup/hold or recovery/removal. If the latter, shouldn't it be considered asynchronous? My understanding is synchronous reset should be going through the D input of the registers.

Thanks.

--- Quote End ---

The Q2 output can be connected either to the async register port(Altera recommends and saves resource) or applied through D input(Xilinx prefers, wastes resource).

In either case the reset signal must be presynchronised to help achieve recovery/removal if applied async or setup/hold if applied through D input.

--- Quote Start ---

The Q2 output can be connected either to the async register port(Altera recommends and saves resource) or applied through D input(Xilinx prefers, wastes resource).

In either case the reset signal must be presynchronised to help achieve recovery/removal if applied async or setup/hold if applied through D input.

--- Quote End ---

Thanks for the explanation. So in summary, synchronous de-assertion is not really necessary for Altera's devices since it has already been taken care in rec/rem. Only those that do not have async reset port will benefit from it. Do correct me if my understanding is incorrect.

--- Quote Start ---

Thanks for the explanation. So in summary, synchronous de-assertion is not really necessary for Altera's devices since it has already been taken care in rec/rem. Only those that do not have async reset port will benefit from it. Do correct me if my understanding is incorrect.

--- Quote End ---

wrong. That is what you did by having double synchrinoser. The reset is termed synchronised (or what I call pre-synchronised and applied either way). I think you assume the case of wiring to async port as async, well it is locally but the incoming signal is pre-synchronised so that it doesn't de-assert anytime at will by controlled by clock edge.