Quartus fixing hold violations but not setup

[Altera_Forum]

Hello, 

 I am trying to create a design which uses the LVDS inputs on a stratix II. The design I have works to a degree but I am having issues with my input constraints (sdc file) which is causing the design itself to synthesis unreliably.  I have implemented my own ddr retime block and deserialiser (I am not using the in built LVDS receiver as I want the design to work over multiple frequencies). The issues I am having is with regard to the input capture flop. When I synthesize the project the timequest timing analyser claims that the setup time on a given capture flop is failing by ~0.317ns but the hold violation is passing 0.378ns.  My question is; if the tools know that a given path is failing setup time but not hold and there is enough slack in the hold time to fix the violation in the setup time. Why are they not going back trying to repair that path?  This issue seems like it avoidable and it just means that I cannot run the design at the speed I want to run it at but I am wondering when it may be possible to repair the positive slack, why is it not doing so?  Any help I can get with this would be appreciated.

[Altera_Forum]

--- Quote Start ---  Hello,  I am trying to create a design which uses the LVDS inputs on a stratix II. The design I have works to a degree but I am having issues with my input constraints (sdc file) which is causing the design itself to synthesis unreliably.  I have implemented my own ddr retime block and deserialiser (I am not using the in built LVDS receiver as I want the design to work over multiple frequencies). The issues I am having is with regard to the input capture flop. When I synthesize the project the timequest timing analyser claims that the setup time on a given capture flop is failing by ~0.317ns but the hold violation is passing 0.378ns.  My question is; if the tools know that a given path is failing setup time but not hold and there is enough slack in the hold time to fix the violation in the setup time. Why are they not going back trying to repair that path?  This issue seems like it avoidable and it just means that I cannot run the design at the speed I want to run it at but I am wondering when it may be possible to repair the positive slack, why is it not doing so?  Any help I can get with this would be appreciated.  --- Quote End ---    One scenario is that if your set_input_delay max is too much then the fitter can't insert negative delay (i.e. inserting delay in clock instead of data) so it will violate setup while hold is safe. The fitter cannot simply look at timing window and move the transitions centred on the window. One way to help fitter is use pll to rotate the clock.

[Altera_Forum]

--- Quote Start ---  One scenario is that if your set_input_delay max is too much then the fitter can't insert negative delay (i.e. inserting delay in clock instead of data) so it will violate setup while hold is safe. The fitter cannot simply look at timing window and move the transitions centred on the window. One way to help fitter is use pll to rotate the clock.  --- Quote End ---    Hey Kaz,  Thanks for the response. I actually discovered a solution yesterday evening. Like I said I had coded my own ddr retime block, however when this was implemented it seemed to use generic combinatorial blocks within the fpga. I changed this to use the altddio mega-wizard function in the hope that this would use dedicated hardware to the input capture and it seems to, at least it does on the resource property planner anyway. It still fails setup and hold time but now only by 30ps or so. Even though this is still out of spec, the Tx I am testing does not have a spread as bad as the spec so we should hopefully be ok. It seems to work on the bench now in any case.  I suppose I can tighten the specs a bit more and maybe experiment with seeds to see if I can get any more marginal gains but for our purposes it should be ok.  Cheers again for the response!!