What's the purpose of set_clock_latency ?

[Altera_Forum]

We have a StratixIV design that if built 20 times with quartus, will fail 18 times when run on the board.  

 Timing of the failing build is very similar to the timing of the "good" build.  The constraints file has a set_clock_latency -source command. If it is removed, then 20 builds will pass.   We can't do a gate level simulation as the design includes both a PCIE and a DDR2 controller.  Why does the set_clock_latency constraint impacts the design implementation 20% of the time, not more or not less?  Any explanations or ideas of areas to investigate?

[Altera_Forum]

As far as I can understand it, "set_clock_latency -source" it's one way to model the delay between a clock source (ie, an oscillator) and the FPGA pin, when setting I/O delay constrains. 

 I've never used it, though. I just account for that delay into the I/O delay value.  My guess that it will affect timing for all I/Os based on that clock and derived clocks. No clue on why it only causes problem's 20% of the time but if the design is at the limit... small things can make the difference.  If if were me, I'd try to redefine the I/O constrains without set_clock_latency.

[Altera_Forum]

What's the value of set_clock_latency? This command adds delay to the clock and can be used to model external clock delays. Unless multiple related clocks are coming into the FPGA, it only affects I/O timing, but it certainly will give a different result.  

If the constraint is incorrect, then you're compiling with incorrect timing analysis and some of the time it may just happen to still pass. But the thing to investigate is if the analysis is correct.

[Altera_Forum]

This is the constraint 

 set_clock_latency -source 0.100 uclock

[Altera_Forum]

uclock and all generated clocks from it(and generated clocks from those generated clocks) will now have an extra 100ps delay. Anything analyzed between those clocks will not see it, since the 100ps will cancel out between the source clock and destination clock paths. But to other clocks not related, it will affect the setup and hold analysis by 100ps. 

If the clock is delayed 100ps, then it's correct. If it's not, then it's not correct. Who put the constraint in?

[Altera_Forum]

--- Quote Start ---  uclock and all generated clocks from it(and generated clocks from those generated clocks) will now have an extra 100ps delay. Anything analyzed between those clocks will not see it, since the 100ps will cancel out between the source clock and destination clock paths. But to other clocks not related, it will affect the setup and hold analysis by 100ps. If the clock is delayed 100ps, then it's correct. If it's not, then it's not correct. Who put the constraint in?  --- Quote End ---    Thanks for your input.  One of the designer put the constraint in at the beginning of the project. When, at the end of the project, we realized that we could not get consistent reliable builds with no negative slack, we examined all of the constraints, and since we could not tell why this one was needed, we removed and builds are now all good.

[Altera_Forum]

Note that you can retime an image after changing the .sdc. For example, take one of the failing designs. After compiling, remove the set_clock_latency from the .sdc and run TimeQuest. Hopefully something pops up as failing, and you know what the issue is.