Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

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

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?

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    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.