Recovery errors with Time Quest Timing Analyser

Just to be sure, did you look at recovery/removal in this document:

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

(I wrote another one called Understand Recovery/Removal, but this one is more up to date.)

My initial question is about how the system works. TimeQuest analyzes asynch reset signals with synchronous timing, which is a good thing. But if the signal is coming in from a truly asynchronous source, say a pushbutton or out of a device on another clock domain, there is no reason to have TQ try to time it, since it's not a real analysis. You would need to enter an asynchronous assert/synchronous de-assert circuit.

- Synchronizing it with a double-flop synchronizer could also be used to get it into the main clock domain, but you lose the asynchronous assert capabilities. Quite often that is not a big deal.

- I do not fully agree with Kaz's comment. I get the point and agree in principle, but in practice it has the user constantly going "does this need a reset?". There is no easy way to test if the user's answer is correct either. I find it safer to just reset everything. I also don't think this hurts timing, as usually right by the data path that wouldn't have a reset is some control logic that does, so if it can meet timing to the control logic, it would have met timing to the data path. The only major advantage is if the reset is using local routing, it would save a little bit, but that's usually not too big of a deal. I just think the risk of not adding a reset to the wrong signal and the extra engineering time figuring it out are not worth it. (I'm working with someone who has a reset failure right now, where one build occasionally fails out of reset. Most other images of that build happen to meet timing. It's a complete nightmare to debug and prove why it's occurring.)