Timequest and ripple clocks ... how to set up?

Strange. The FFS are far apart, so there will be a decent amount of delay. I think one of two things is happening:

a) The fitter thought the hold requirement was larger(on-die variation is going to be bad for these long paths), and so it added delay to meet hold timing. One way to check this is to go to Assignments -> Settings -> Fitter and disable Optimize Hold Timing. Recompile and see if the setup failures go away. (You will have hold failures). Another thing to do is a report_timing on that path to see how much it meets hold by right now. You may have to check the other timing models to see which is worst.

b) The placer thought it was going to meet setup timing, but when it routed it couldn't. It may have been confused by the long clock trees. If that's the case, you can overconstrain it by adding something like:

if {$::quartus(nameofexecutable) != "quartus_sta"} {

set_max_delay -from [get_clocks *|clkdiv_160M|*] -to [get_clocks *|clkdiv_80M|*] 6.0

}

This over-constrains it in the fitter but not the final timing sign-off. Note that if it's a hold timing issue where it's adding delay, you could do the opposite by loosening the hold requirement with:

if {$::quartus(nameofexecutable) != "quartus_sta"} {

set_min_delay -from [get_clocks *|clkdiv_160M|*] -to [get_clocks *|clkdiv_80M|*] -0.2

}

More basic, why can't you have the PLL create multiple clock outputs? I think that would be the easiest solution as they would all be aligned nicely.

(I'm a bit surprised the clock enables are that much worse. If you used enables, you would have one global clock line toggling at 320MHz and then a lot of logic that gets enabled/disabled. With this new implementation, you still have the global toggling at 320MHz, but the 160MHz and 80MHz(and probably all of them) are feeding additional Global clock lines, which consumes a decent amount of power.