Timeline for Reset: synchronous vs asynchronous
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 30, 2011 at 7:42 | vote | accept | Aurelien Ribon | ||
| Nov 3, 2011 at 3:12 | comment | added | mixed_signal_old | The reset input to the flops is considered by most static timing tools, so synchronous de-assertion can be properly timed in synthesis and place&route extracted static timing checks. | |
| Nov 3, 2011 at 0:25 | comment | added | Oli Glaser | Sorry, I think I see what you mean now. If you mean the output from the second latch in the synchroniser to system FF reset, my understanding is that the reset recovery time is typically less than the data setup time for the same FF, so it should be okay. I agree about the runt pulses, it offers no immunity to those without something like you suggest being implemented. | |
| Nov 2, 2011 at 23:37 | comment | added | supercat | Upon further consideration, one could add protection from runt pulses by adding a third latch, and having its async reset signal be a glitch-suppressed version of the signal fed to the first two, such that a signal which asynchronously disturbed the third latch would be guaranteed to cleanly reset the first two. A runt pulse on the reset input could cause the main reset line in the chip to get a runt pulse, but if such a pulse occurred it would be followed by a synchronous reset pulse. | |
| Nov 2, 2011 at 23:18 | comment | added | supercat | My question is whether having a latch1 release the reset signal feeding latch2 on the same clock edge as latch2 would be using is completely kosher, i.e. whether the minimum propagation time from latch1's clock to its output would satisfy hold requirement for latch2's reset input. BTW, what do you think of my answer above? The circuit you drew offers little immunity to runt pulses on the reset line, when almost total immunity should be possible. | |
| Nov 2, 2011 at 17:07 | comment | added | Oli Glaser | No, the release of reset asynchronously is not guaranteed to be clean due to reset recovery time needed (like setup/hold) This is why you would release the reset synchronously. | |
| Nov 2, 2011 at 16:06 | comment | added | supercat | How do the setup/hold time requirements between the release of a latch's reset signal and its clock compare with those for the data input? I would feel more comfortable if the latches in the system saw the end of the reset signal occur on the inactive clock edge. Would the release of an async reset on an active clock edge be guaranteed not to affect the cycle where it occurs? | |
| Nov 2, 2011 at 15:43 | history | answered | Oli Glaser | CC BY-SA 3.0 |