Problems upgrading from Quartus 5.0 to 7.1

[Altera_Forum]

Has anyone had any problems migrating from an older version of Quartus to the newest version. I have a fairly large design on a Stratix I, and it compiles fine with Quartus 7.1 but it does not work when I run it on the device. Any suggestions? If it is a timing problem, I have thought about LogicLocking the timing critical modules.

[Altera_Forum]

If there is any OpenCore IP in the design, you might need a patch for QII 7.1. Make sure you don’t have any OpenCore messages from licenses that have expired. If you do need to do an OpenCore compilation, see http://www.altera.com/support/kdb/solutions/rd07272007_148.html. 

    --- Quote Start ---  ... it compiles fine with Quartus 7.1.  --- Quote End ---    If "compiles fine with Quartus 7.1" means there are no reported timing violations, it might be that you have real timing violations in hardware that are not reported in Quartus because you do not have the timing constrained properly. You might have just been lucky that the design worked when compiled with the earlier Quartus version. If you are using the Classic Timing Analyzer, begin your check for this problem cause by running "Processing --> Start --> Start Classic Timing Analyzer Constraint Check".  You might have something asynchronous in the design where the timing actually matters because you didn't design for the asynchronous paths (using metastability registers for crossing between clock domains, using handshaking, etc.), because you didn't intend there to be asynchronous paths, or because your design needs recovery/removal analysis but you didn't enable it in the "More Timing Settings" dialog box.  "Processing --> Start --> Start Design Assistant" might turn up asynchronous problems--as well as produce a bunch of warnings that might not make a lot of sense. You'll just have to wade through the messages and try using the on-line help on the right-click menu of the Design Assistant warnings to figure out whether it found anything that really is a concern for your design.     --- Quote Start ---  I have thought about LogicLocking the timing critical modules.  --- Quote End ---    Don't use LogicLock to solve timing problems unless you really know what you are doing. LogicLock is more likely to hurt the timing than to help it. On most designs it is better used for floorplanning (for example, to make it easier to use incremental compilation) than for increasing timing performance.

[Altera_Forum]

Good post, Brad. (Whoever you are...). I like the Design Assistant to look for potential issues, but if you actually are having hardware failures, I would recommend debugging it like a hardware failure. Analyze the failure state. Run sims. Use SignalTap and/or SignalProbe. Etc. I've seen many users spend a lot of time "trying different things". Occasionally it works. Often it doesn't and you've wasted time. But the worst case scenario is if it randomly starts working, and you attribute it to the change you just tried, but they're not really related. Now your design marginally works, and might fail in the field, with any design change at all, etc.. If you identify the problem, you can be certain of creating the correct solution. 

 Of course, this depends on the application. If you're trying to get something to work for a university course, that's probably fine. If you're making medical equipment...  Good luck.