Bad placement result from Quartus 13.1.0 and How to work around?

Your clock constraints already tell the fitter what's important and I'm guessing it knows that it's not meeting timing but can't do anything. Does this specific path break every time or does it hop around to signals like it. Note that just moving the source LUT closer won't meet timing, it just pushes the long hop further back in the path. You have to move the entire path closer. But the LUTs have fanouts of 17, 53, 18, etc. Those often multiply up(i.e. the fanout 17 node drives 17 nodes, all with a fanout of ~50, etc.) So you may have hundreds or thousands of nodes that all need to move with it, or might have their timing break if you moved just this path. Run:

report_timing -setup -npaths 500 -detail path_only -pairs_only -from "source_register" -panel_name "Critical Source's 500 fanouts"

Just replace source_register with the source register in this path. After it lists the 500 nodes, highlight them all and right-click Locate in Chip Planner. (You'll have to double-click on the 500 paths in the Locate window there). You'll see where the top 500 paths go.

Bottom line is that it's probably not a trivial problem that the fitter wasn't working on, but something that is very complex and that's the solution it came up with. As Tricky says, please run multiple seeds and analyze the results. See if it' the same path every time, or does it hop around to other things completely or similar paths? Does the slack get a lot better and this is an outlier, or do they always fail by this much.

I often suggest manually duplicating logic, but the large fanout node is so far down the combinatorial logic it may be hard to do. If there's anything you can do in the code that would help, that's the first place to look. As for Quartus settings, try Tools -Advisors -> Timing Optimization Advisor and try the High Effort Fmax settings(basically these are the buttons you can push to help get better performance). It's seldom enough to shave 700ps off a design, but might be worth trying. Monitor if your compile time goes up though, since that's the main trade-off, and see if the trade-off is worth it.(If compile time goes up by 2 hours and you only get 100ps better performance, it may not be worth it. And remember that you need to run multiple seeds both before and after the changes to real gauge what they do...)