Apparent Reset Glitch on Synchronous Reset

Note that, although it is recommended to follow a coding pattern for doing resets, enables, etc., this is more for the purpose of easily readable/writable code, as well as making sure you can take advantage of the dedicated logic surrounding the FFs. (The Quartus II handbook talks about FF signal priority in Recommended Coding Styles). For example, the clock enable has priority over a synchronous reset. If you code the synchronous reset with priority, then this can't be implemented in the dedicated register silicon and will have to be done in the LUT before it(i.e. the clock enable will be a feedback mux) in the LUT, and you're design will get bigger/slower.

That being said, if you code in a different manner, it should still always work. A feedback mux in the LUT should function just like an enable. If something doesn't work, there's almost always a good reason.

When dealing with asynchronous resets, be sure to understand Reset/Recovery. Almost all designs have asynch resets, and yet Reset/Recovery is one of the least understood topics in static timing analysis. It is off in the Classic Timing Analyzer by default, but can be turned on under Assignments -> Settings -> Timing Analysis -> More Settings -> Reset/Recovery Analysis. It is on by default in TimeQuest.

Note that this is not the issue with the original post. If you fail Reset/Recovery, it just means your registers will go into the reset or come our of the reset state one clock earlier or later than expected. But it will not "glitch". As for this glitch, I still do not believe it is a glitch, at least in the classical sense. Is everything on the same clock domain(the original three registers that create the glitch as well as the registers the reset feeds)? Do the three reset signals have any FF controls, like their own asynch reset, or do they just use the D, CLK and Q port? Just some more things to look at. (And for clarification, the title says Synchronous Reset, but it feeds all the destination registers through the asynch reset port, correct?)