Honored Contributor
Honored ContributorJust another thing to look at:
http://www.alteraforum.com/forum/showthread.php?t=1845&highlight=timequest If you see failures in your design, it is very important to understand what is being analyzed and how it is being analyzed. Once you get that, you then need to correlate it back to your design. Note that TimeQuest analyzes your design against your constraints. Crossing asynchronous clock domains is the classic example. If you have logic going through an asynchronous FIFO, that doesn't mean no physical paths exist between the clock domain, and TimeQuest doesn't decide whether to analyze those paths or not. By default, all clock crossings are analyzed, and only a set_clock_groups or set_false_path constraint can be used to tell TimeQuest not to analyze them. So your question of whether a clock-crossing block is inserted doesn't mean the paths don't exist in TimeQuest. Now, your SDC looks good on first glance except for your IO timing. You have your input delays with a max of 1.0 ns(so you're requiring it to be less than 1ns) and a min of 2.0ns(requiring the same path to be greater than 2.0ns). Naturally, that's not possible and one of those will always fail. Generally you should have 1 SDC. All constraints should be used by the fitter. Some won't be used by synthesis but there's nothing you can do about that and it still works really well(i.e. don't worry about that). In TimeQuest you can do a report on Unconstrained Paths, which is important to see if you miss anything. Bottom line is you're going through some growing pains from a) I want to do as little timing analysis as possible to b) I'm trying to do it right but it's more complicated than I thought. This is normal, and keep progressing. The big thing you're avoiding is "inconsistent behaviour", which really means a design that doesn't meet timing, and just happens to work all the time. A good design that meets all timing requirements should work all the time. As for how much constraining to do, everything should be constrained. What that means is that you correctly constrain all your clocks and all of your I/O, which I believe you've done(although the generic way the I/O have been constrained is reason to pause). Now everything has clock relationships and all transfers have requirements. Technically you have everything constrained, and what you do from there is "loosen" constraints. So your set_clock_groups command is telling TimeQuest not to analyze paths betwen unrelated clocks. set_false_path commands do the same thing, as do multicycles(which make the constraints looser). Anyway, hope that helps.
