Forum Discussion
Altera_Forum
Honored Contributor
14 years agoThere's two components to the synchronizer:
1) The path from a register in one domain to the first register in the other domain. This is asynchronous and the user should cut timing on it. (I suggest cutting timng between the domains with set_clock_groups). This path should have no affect on MTBF and not be analyzed. 2) The next part are is the path to the second register(and if there are more synchronization stages, the path to each). These are all in on the same clock domain, should be analyzed by TimeQuest as a pass/fail on whether it met timing, and then analyzed for MTBF based on how much positive slack. As you mention, if the slack is negative there is no MTBF, as it will always fail. Anyway, the asynchronous path and the synchronizer should be two separate things. Out of curiosity, how do you like the MTBF analysis? I don't see this used very much although think it's a very cool tool. (My feel with metastability is that it's generally easy to fix if you have a way to identify and analyze it. Most tools don't do this, while TimeQuest actually does a very good job.)