Timequest and PLL jitter

[Altera_Forum]

Hi, 

is it necessary to specify any timing jitter when using PLL outputs in an SDC file i.e. as well as the derive_pll_clocks command? Is there anything else I need to do to make sure I'm covering myself timing wise?  I'm getting some wierd results on Stratix III even though my timing analysis is reporting positive setup and hold slack. I've done what I believe to be a pretty thorough job of specifying the timing constraints but I'm beginning to wonder if I've missed anything.  Do constraints attached to the external clock input have an impact on PLL clocks? I have not specified jitter on the external clock inut and wonder if this may be a problem.  Thanks, D.

[Altera_Forum]

--- Quote Start ---  is it necessary to specify any timing jitter when using PLL outputs in an SDC file i.e. as well as the derive_pll_clocks command? Is there anything else I need to do to make sure I'm covering myself timing wise?  --- Quote End ---    derive_clock_uncertainty accounts for PLL jitter. This command is required for 65 nm (like Stratix III) and newer device families. In QII 8.1 you get a warning for those families if you don't use clock uncertainty and an Info message if you manually add less uncertainty than would be added by this command.  From the derive_clock_uncertainty on-line help page:    --- Quote Start ---  This command auto-generates a file named PLLJ_PLLSPE_INFO.txt... that lists the names of the PLLs in the design as well as their jitter and SPE values.  --- Quote End ---        --- Quote Start ---  Do constraints attached to the external clock input have an impact on PLL clocks? I have not specified jitter on the external clock inut and wonder if this may be a problem.  --- Quote End ---    Some configurations of PLLs let the input jitter pass through to the output. The Stratix III device handbook says, "A high-bandwidth PLL provides a fast lock time and tracks jitter on the reference clock source, passing it through to the PLL output." I filed a service request asking how this case is handled with derive_clock_uncertainty. I was told that derive_clock_uncertainty gives an uncertainty based on the maximum possible output jitter for the maximum allowed input jitter for PLL configurations that let the input jitter pass through the PLL. You don't need to add clock uncertainty manually to the device input pin driving the PLL if that pin is used only by the PLL. I didn't ask about the case where that input pin also clocks registers directly, but you can check the TimeQuest report to see whether derive_clock_uncertainty is creating uncertainty for that case.

[Altera_Forum]

--- Quote Start ---  I'm getting some wierd results on Stratix III even though my timing analysis is reporting positive setup and hold slack. I've done what I believe to be a pretty thorough job of specifying the timing constraints but I'm beginning to wonder if I've missed anything.  --- Quote End ---     Even though you were careful, review these reports if you haven't already: 

• Report Ignored Constraints 
• Report Unconstrained Paths 
• Check Timing 
• Design Assistant 

[Altera_Forum]

1) Constraints on the external clock(such as clock uncertainty) do not pass through to the lower level clocks. That would be far too pessimistic, as PLLs tend to filter out any noise. (I believe the Fitter Report -> PLL Summary has a Bandwidth value for each PLL, whereby it filters noise out of that bandwidth(I think), so if you do a spectral analysis of your input jitter and find what passes through, you could add it in. To date, I've never seen or heard of anyone doing that.) 

2) If you do want to add uncertainty, append -add to your derive_clock_uncertainty, so any specific uncertainties you add will be additive values, rather than overwriting the values calculated by derive_clock_uncertainty. 3) I would be wary of debugging at this level, i.e. looking for broad level things like PLL jitter, board level VCC sag, ground-bounce, I/O spice analysis, etc. You could spend a lot of time and never uncover anything. I would strongly recommend getting your hands dirty and start SignalTapping as much as you can until you capture an failure, and then start diagnosing what could have caused it. Although this can be a very slow process at first, you at least always know you are progressing towards a solution. 4) One other thought is too just look at your slacks. All uncertainty does is take some values off your setup and hold slacks. If you feel it's too close, try shooting for more margin. (This is more straightforward with setup, but trickier with hold. By default, many paths will have very low hold margin, like a register feeding another register in the same LAB. That being said, by the nature of the layout there will be even less clock skew and it would be impossible to get a hold violation, so even though it's close, you shouldn't worry about.)

[Altera_Forum]

Thanks for your help, I really appreciate it. 

 So, as a first pass I will add the derive_clock_uncertainty clause to my sdc file. At leat I will then know if I'm way out.   The lower end of my setup slack distribution curve is quite low (100pS or thereabouts), so yes I could try setting a minium slack constraint. I'm not so sure what margin I should use though, until now I have assumed that any value of positive slack is OK given that I'm checking all 3 v-t points.  I do take the point about SignaTap. I do use it when I hit problems and it has proven to be extremely useful.

[Altera_Forum]

Note that it's a slippery slope to start padding your numbers, especially when you're not sure why or what values to use. One other point is that I'm certain the part you're testing in the lab is not the worst one in the bin out of the FAB(Process), and isn't at worst case Voltage and Temperature, so it's operating faster than the Slow Model being timed against. So you have 100ps of slack assuming all of these worst case conditions, but you should have quite a bit of slack within the part/s that are acting up. (Under lab conditinos, designs that don't make timing by ~10% are usually run and work fine.) So that being said, and not knowing anything about your design or issues you're seeing, my guess is that's not your problem and you should concentrate elsewhere. (Heck, put a fan next to the part of shoot it with cold-spray and see if that fixed the problem. If it doesn't, it's not a setup issue).

[Altera_Forum]

(Expanding on the slippery slope comment...) 

I've seen customers do this in the past and say they had to for another companies devices(many years ago, so take with a grain of salt, and I really don't know if the customer was right or not). But I have seen people pad numbers like this at big companies. Designs get passed around and another group suddenly gets asked if they pad their numbers of not. Or a design has trouble meeting the padded requirement, and they spend all this extra time trying to close timing, and questioning why it's there in the first place, which nobody really knows.  (One other thing I've seen for X designs is whereby they say the fitter will do better if you over-constrain your critical paths, and I've seen people try that with Altera devices. In general you shouldn't have to do that, as the fitter already knows what is critical, but the worst case is you know have an area where the design could fail the over-constraints but pass the timing you want, which causes a headache for analysis...) Just some thoughts...

[Altera_Forum]

No, they concur with my thoughts really. As far as I'm concerned, my job is to ensure the functionality/logic is correct and to specify the timing requirements as they are to Quartus. From there on, the tools should do the rest. So, I'm not going to add any false padding. I will add the clock uncertainty though as I think this is perfectly valid (and recommended by Altera). 

 And, yes, there is still a suspicion that I've got something wrong in the logic - I'm currently double checking my simulation testbench.  Thanks for everything.

[Altera_Forum]

I think I spoke too soon. I have had my rig off for about an hour and it was fine on power up and then things started to go flaky after a few minutes. A quick squirt of freeze-it quietens the problem down (it's a DSP audio application). 

 So, it is definitely timing related...

[Altera_Forum]

My advice is that you concentrate on your hold timing. Make sure your hold constraints are ok (e.g. you didn't accidentally false path or multicycle a path you did not intent to). Use the check_timing and report_timing functionality to help you out. Also put special attention to your I/O timing, another area people tend to make mistakes when constraining. 

 It is hold timing, by the way, the main reason you should not pad your timing. Padding may help you with setup timing, but will hurt your hold.  And yes, definitely use derive_clock_uncertainty.