Does the order of the timing constraints make a difference to the Fit?

[Altera_Forum]

To "fudge" a project for now (a release is coming up - RTL changes will be needed but not enough time), I have a load of set_max_delay constraints that will only apply to the fitter ( if { $current_exe == "quartus_fit" } etc). I am running 12 seeds a night and not meeting timing, but the following is frustrating me. I have the following registers in a 368MHz clock domain. 

 A->B->C  I set a max delay constraint of A->B of 2.0ns on one run. Results were that the failure now occurs B->C  I added another constraint for a max of B->C 2.0ns. This then caused A->B to fail a lot again.  Register A is inside a DSP slice, so it cant move. But I suspect the 2nd constraint is "pulling" B away from the DSP again.   So would the order of the set_max_delay constraints make a difference?

[Altera_Forum]

Order doesn't matter on different paths. They both get applied, and the fitter works on them all. 

What's C -> *? Does that meet timing relatively easily?  My experience is the fitter sometimes is not good about placing pipeline registers(although I hear it's being worked on). That being said, overconstraining like this should fix it. I wonder if there's a higher-level topology issue occurring. For example, let's say there are a bunch of DSPs(A) that feed their own B and C and those all merge to one point(or lots of points). In this case, the DSPs are placed in their stripe locations, which are naturally spread out a bit, and so all these locations must converge to a single point. Basically it can't place all these A -> B -> C -> ? and meet timing. Overconstraining pushes around who fails, but at a higher level something always ends up failing. I have no idea, but just a thought as to what may be happening.

[Altera_Forum]

Theres basically two paths, a real path and imaginary, in two separate entities, so there should be only 4 DSP slices for A. But the problem is A -> B has rounding and saturation logic, so I get a load of failed paths because each bit of B is affected by the high bits of A. 

 I just had a brainwave - dont the DSP slices in S4 have different round and saturate modes? currently the mult is done with an lpm_mult megafunction (not my code). Would we be better served using a multadd block instead so we can specify the round/saturate in the DSP block, rather than do it in logic.

[Altera_Forum]

Yes, it does. (Beyond that, I don't know the details.) Good luck.